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Introduction 


This document, the PC/ Mobile Paymenis on COTS (MPoG) standard (hereinafter referred to as the “MPoC Standard” or “standard”), defines 
security reguiremenis, test reguiremenis, and guidance for entities involved in the development, deploymenit, and operation of merchant 
operated mobile payment acceptance solutions that use COTS devices. 


Solutions that do not use COTS devices, use devices that are intended for integration into another product, or solutions that are intended for 
use by the cardholder themselves using their own COTS device, are not considered by this standard. Similarly, MPoC does not consider or 
allow for solutions that are to be deployed into an environment that is not merchant attended. 


The security reguirements described in this document provide a security framework to protect the confidentiality and integrity of sensitive 
payment information captured and processed in MPoC Solutions. The test reguiremenis outlined in this document provide details of the testing 
processes performed by the evaluation laboratories as part of the validation testing of the solutions. 


The MPoC standard allows for an optional modular approach to the development of a mobile payment solution. An MPoC Solution is 
considered a monolithic solution if the MPoC Solution does not use or integrate any other listed MPoC Products, and instead is assessedasa 
complete implementation. Alternatively, an MPoC Solution may be considered a composite solution if it does use and/or integrate one or more 
listed MPoC Products. The following bullets provided below outline the different types of MPoC Product that are supported by this standard for 
separate validation and listing: 


" oOMPoC Software: All software that implements the base functionality reguired by the MPoC Solution, including the functionality for 
accepting account data (optionaliy including the cardholder PIN) on COTS devices. The MPoC Software must implemeni at least 
one form of COTS-native account data entry, either COTS-native NFC or COTS-native PIN eniry. The MPoC Software scope also 
includes the attestation componenis, back-end functionality, and any APls offered. The backend may optionally also include the 
paymenit processing environment and functionality. 

MPoC Software may rely on hardware functions or systems, such as those provided by the COTS platform(s) or back-end HSMSs. 
MPoC Software that is separately validated and listed on the PCI SSC website is considered an MPoC Software Product. 


" oAttestation and Monitoring Service: The operation of the attestation and monitoring functionality of a listed MPoC Software 
Product. An Attestation and Monitoring Service cannot be used by an MPoC Solution that is not using an MPoC Software Product 
supported by that Attestation and Monitoring Service. 


" oOMPoC Solution: The set of components and processes that supports mobile payment acceptance and protection of account data 
on a COTS device. At a minimum, the solution includes the MPoC Application, attestation system, and the back-end systems and 
environmenis that perform attestation, monitoring, and paymenit processing. 


The reguiremenis in this standard are organized in five Domains. The first two Domains cover the technical and development aspecis of the 
software of the MPoC product (the MPoC Software, or eguivalent functionality in as implemented in a monolithic MPoC Solution (Domain 1)), 
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and the MPoC Application (Domain 2). The last three Domains cover the operational aspects of the MPoC Software, Attestation and 
Monitoring Service, and MPoC Solution. 


" oDomain 1: MPoC Software Core Reguiremenis: The security and test reguiremenits that apply specifically to the MPoC 
Software and MPoC Software lifecycle processes. The core Module in this Domain includes security reguiremenis such as secure 
software and secure software lifecycle processes, integrity protection, sensitive information protection, and secure channels. This 
Domain includes optional Modules and Sections that are applicable only to MPoC Software supporting the relevant payment 
acceptance or cardholder verification methods (such as COTS-native NFC, or COTS-native PIN entry). 


" oDomain 2: MPoC Application Integration: The security reguirements and test procedures that apply to MPoC Applications, 
including those that integrate previously assessed MPoC Software. The reguiremenis in this Domain include the secure 
integration and usage of the MPoC Software, and the security of the complete MPoC Application. 


" Domain 3: Attestation and Monitoring: The security reguiremenis and test procedures that apply specifically to a service 
provider operating the back-end attestation and monitoring environment(s). This service provider is responsible for maintaining the 
COTS platform baseline, interpreting and responding to data collected from the COTS platforms, and the security of attestation 
and monitoring environment. 


" Domain 4: MPo€ Software Management: The security reguiremenis for the operational management of software producis and 
the management of cryptographic keys and encryption systems used in the MPoC Solution. This includes the security 
reguiremenis for signing and distribution MPoC Software and MPoC Applications, and the key management for these software 
products as well as back-end systems. The MPoC Software Management Domain may apply to more than one entity within an 
MPocC Solution. 


" oDomain 5: MPoC Solution: The security reguirements and test procedures that apply to MPoC Solution providers who are 
responsible for managing the interaction between all parties in an MPoC Solution, and the security of any MPoC specific 
decryption or (paymeni) switching environmenits. The MPoC Solution provider is also responsible for ensuring that any associated 
MPoC Applications, which are not already listed as part of an MPoC Software Product, meet the reguiremenis of this standard and 
are included as part of their MPoC listing. 


Roles and Responsibilities 


There are several stakeholders involved in maintaining and managing PCI standards. The following describes the high-level roles and 
responsibilities as they relate to the PCI Mobile Payments on COTS standard. 


« OPCISSC — PCI SSC maintains various PCI standards, supporting programs, and related documentation. In relation to this 
standard, PCI SSC: 


— Maintains the Mobile Paymenis on COTS Security and Test Reguiremenis (this document). 
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— Maintains supporting documentation including reporting templates, attestation forms, technical freguently asked guestions 
(FACOs), and guidance to assist entities implementing and assessing to the standard. 


— Reviews and monitors Evaluation Reports and related change submissions submitted to PCI SSC by PCI Recognized 
Laboratories for completeness and competency with baseline guality, security, and security testing standards. 


— Maintains engagement with the industry security evaluation stakeholders to ensure that the evolving threat landscape is 
effectively addressed during the evaluation work. 


— Maintains the list of approved PClI-recognized labs gualified to perform evaluations using this standard, on the PCI SSC 
website. 


— Maintains a guality assurance program for PCI-recognized labs. 


Participating Payment Brands — The participating payment brands develop and enforce their respective programs related to 
compliance with PCI standards including, but not limited to: 


— Reguiremenis, mandates, and deadlines for compliance to PCI standards. 
— Which organizations are reguired to comply with PCI standards. 


PCI-Recognized Laboratories — PClI-recognized laboratories are responsible for maintaining the reguired knowledge, expertise, 
and eguipment necessary to execute all test activities, and to perform the reguired evaluation and generate an evaluation report 
documenting the results. Not all PCI-recognized laboratories are gualified to perform evaluations using this standard. For further 
information, please consult the Mobile Payment on COTS Program Guide. 


EMVCo — EMVCo is the global technical body owned by American Express, Discover, JCB, MasterCard, UnionPay, and Visa 
that facilitates the worldwide interoperability and acceptance of secure payment transactions by managing and evolving the EMV 
Specifications and related testing processes. Adoption of EMV Specifications and associated approval and certification processes 
promotes a unified international payments framework, which supports an advancing range of payment methods, technologies, and 
acceptance environmenis. 


Additionally, the following entities are identified for the purpose of this standard: 


MPoC Software vendor — The MPoC Software vendor is an optional entity developing, distributing, and supporting the MPoC 
Software. An MPoC Software vendor is responsible for ensuring that the MPoC Software they develop meets the reguirements 
outlined in Domain 1: MPoC Software Core Reguiremenis. 


Attestation and monitoring service provider — These optional entities are involved in the deployment and operation of the 
attestation and monitoring component of the MPoC Software within a back-end environment. The entity operating the attestation 
and monitoring (A&M) service is responsible for ensuring that all reguiremenis outlined in Domain 3: Attestation and Monitoring 
are met. 


MPoC Solution provider — An MPoC Solution provider is the entity that has overall responsibility for the implementation and 
management of an MPoC Solution. The MPoC Solution provider is responsible for ensuring that all reguirements are met, 
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including any reguirements fulfilled by other organizations on behalf of the MPoC Solution provider (e.g., attestation and 
monitoring service providers). In addition, MPoC Solution providers are responsible for ensuring that any MPoC Applications are 
securely integrated with the MPoC Software, and are securely distributed to merchants. 


Glossary/Terminology 


In addition to terms defined in the PC/ DSS Glossary, Abbreviations and Acronyms!, Software-based PIN Entry on COTS (SPoC) Security 
Reguiremenis, the terms/acronyms listed in Table 1 are used throughout this document. 


Table 1: Glossary of Terms 


Term Definition 


Account data 


Account data consists of cardholder data and/or sensitive authentication data. See Cardholder data and Sensitive 
authentication data. 


AES 


Assets 


Abbreviation for “Advanced Encryption Standard.” Block cipher used in symmetric key cryptography adopted by NIST in 
November 2001 as FIPS PUB 197 (or FIPS 197). 


Assets are elements of the MPoC Solution that are security-sensitive or are used to provide security to other security-sensitive 
elemenis. Examples of assets include sensitive assets such as account data, cardholder PINs, and cryptographic keys. 
Software may also be considered an assets if the correct operation of that software is reguired to provide security protection to 
other assets. 


See also Sensitive assets. 


Asymmetric encryption 


Also known as public key cryptography, asymmetiric cryptosystems are based on the intractability of certain mathematical 
problems. A cryptographic technigue that uses two related transformations, a public transformation (defined by the public key) 
and a private transformation (defined by the private key). The two transformations have the property that, given the public 
transformation, it is not computationally feasible to derive the private transformation. 


Attestation 


The act of attestation in this standard is the interaction between a verifier (possibly server-based) and a prover (possibly client- 
based) to determine the current security state/behavior of the prover based on measuremenis reguests and thresholds 
implemented by the prover. 


Attestation component 


An element of the solution that performs attestation processing. 


! httos/www.pcisecuritystandards.org/pci security/glossary 
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Term Definition 


Attestation system The set of componenits that perform attestation processing for the MPoC Solution. The implementation may be shared across 
different execution environments, which provides a level of validation and assurance of the execution environment in which the 
MPoC Application executes, providing a level of software-based tamper detection and response. 


Its componenis include the MPoC Application attestation component and the back-end attestation component. The latter works 
in close association with the back-end monitoring system. 


Attestation and monitoring The combination of the Attestation System and the Monitoring System. 
system 


(also A&M system) 


Attestation & Monitoring An entity that has integrated the back-end attestation and monitoring component of an MPoC Software Product, and is 
Service provider providing the operational service of that component as part of a listed MPoC Attestation and Monitoring Service Product. 


(also A&M Service provider) 


Attestation and monitoring The software used to implement the attestation and monitoring functions. Attestation and Monitoring software is a reguired part 
software of any MPoC Software Product. 


(also A&M software) 


Back-end systems The set of systems providing the server-side functionality of the MPoC Solution. This includes monitoring, attestation and 
(optional) payment and PIN processing functions. 


Cardholder data At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any 
of the following: cardholder name, expiration date and/or service code. 

See Sensitive authentication data for additional data elements that might be transmitted or processed (but not stored) as part of 
a paymeni transaction. 


Cardholder data environment | The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data. 


(CDE) 

Cleartext Intelligible data that has meaning and can be read or acted upon without the application of decryption. Also known as plaintext. i 
Commercial off-the-shelf A general-purpose mobile computing device (e.g., smartphone or tablet) that is not designed solely for the purposes of i 
(COTS) device payment acceptance. 


(also COTS device) 


Contactless kernel Software that processes contactless transactions. The kernel is selected by the MPoC Application based on the characteristics 
of the transaction and the paymenit instrument (e.g., credit card) supporting the contactless transactions. The kernel contains 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0 November 2022 
© 2022 PCI Security Standards Council, LLC. All rights reserved. Page 12 


» Security . 
Standards Council 


Term Definition 


interface routines, security and control functions, and logic to manage a set of commands and responses to retrieve the 
necessary data from the payment instrument to complete a transaction.? 


COTS-native NFC The subsystem in the COTS device that is part of the COTS platform used to access data, including account data, read from 
contactless cards or other paymenit instruments. The main physical componenis are the NFC antenna and the NFC controller. 

COTS platform The hardware and operating systems (0S) of the COTS device. i 

COTS platform baseline A measurable configuration reference point of the COTS device attributes and COTS operating systems (0S) on which the i 


MPoC Application may be executed. The COTS platform baseline is used for periodic comparative analysis by the back-end 
attestation system to determine changes that would impact the overall security of the COTS device to continue to process 
transactions. 


Cryptographic material All materials involved in the implementation of a cryptographic algorithm or process including keys, entropy seeds, nonces, and 
lookup tables involved in the execution of the algorithm, etc. 


Deterministic Random A deterministic algorithm to generate a seguence of numbers with little or no discernible pattern in the numbers, excepit for 
Number Generator (DRNG) broad statistical properties. Also referred to as Pseudo Random Number Generator (PRNG). 


See Random Number Generator (RNG). 


Dual control Process of using two or more separate entities (usually persons) operating in concert to protect sensitive functions or 
information. Both entities are egually responsible for the physical protection of materials involved in vulnerable transactions. No 
single person is permitted to access or use the materials (e.g., the cryptographic key). For manual key generation, conveyance, 
loading, storage, and retrieval, dual control reguires dividing knowledge of the key among the entities. See Split knowledge. 


Elliptic curve cryptography An approach to public-key cryptography based on elliptic curves over finite fields. 

(ECG) 

EMV©& A payment standard that implements cryptographic authentication, published by EMVCo. i 

EMVCo A privately owned corporation. The current members of EMVCo are JCB International, American Express, Mastercard, China i 
UnionPay, Discover Financial and Visa Inc. 

Encryption Process of converting information into an unintelligible form excepit to holders of a specific cryptographic key. Use of encryption i 


protects information between the encryption process and the decryption process (the inverse of encryption) against 
unauthorized disclosure. 


? EMVCo (https://Wwww.emvco.com/) 
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Term Definition 


Entity The term entity is used to represent MPoC Software vendors, service providers, and MPoC Solution providers, as applicable, 
that are undergoing the review. 


Environment The systems and processes supporting one or more functionalities of the solution—such as the IT environment hosting the 
back-end monitoring system. 


Execution environment The set of hardware and software on which a program is executed. This may be provided through hardware alone, include a 
combination of hardware and software elemenis, or be virtualized and implemented in software such that the execution 
environment can be similarly executed on different hardware platforms. 


See Rich execution environment (REE), Trusted execution environment (TEE)Trusted execution environment (TEE), and 
Secure element (SE). 


Hash A method to protect data that converts data into a fixed-lengtih message digest. A hash is a one-way (mathematical) function in 
which a non-secret algorithm takes any arbitrary length message as input and produces a fixed length output (usually called a 
“hash code” or “message digest”). Hash functions are reguired to have the following properties: 

* It is computationally infeasible to determine the original input given only the hash code, 

* It is computationally infeasible to find two inputs that give the same hash code. 


Hash-based message A code that is produced using hash algorithms rather than a symmeiric cryptographic algorithm. Defined in FIPS 198-1. 
authentication code (HMAC) | see message authentication code (MAC). 


Integrity Ensuring consistency of data; in particular, preventing unauthorized and undetected creation, alteration, or destruction of data. 


Key block A format for storage and transmission of symmetric cryptographic keys that embeds metadata about the key type and use, as 
well as providing cryptographic authentication across the encrypted key and this metadata to ensure that the key and its 
purpose cannot be altered. 


Key check value (KCV) A value used to identify a key without directly revealing any bits of the actual key itself. Also known as key verification check. 


Key generation Creation of a cryptographic key either from a Random Number Generator (RNG) or through a one-way process utilizing 
another cryptographic key. 


Key management The activities involving the handling of cryptographic keys and other related security parameters (e.g., initialization vectors, 
counters) during the entire life cycle of the keys, including their generation, storage, distribution, loading and use, deletion, 
destruction, and archiving. 


Key verification checks See Key check value (KCV). 
(KVC) 
Key wrapping A process by which a cryptographic key is protected in integrity, confidentiality, or both by the generation of a key block to 


encapsulate (encrypt) the cryptographic key material for transport or storage. 
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Magnetic stripe reader (MSR) | A device that is used to read magnetic stripe cards. 
See also Non-PTS approved MSR. 


Mandatory access control Access control by which the operating systems (0S) constrains the ability of a process or thread to access or perform an 
operation on objects or targets such as files, directories, TCP/UDP ports, shared memory segmenis, |O devices, etc., through 
an authorization rule enforced by the operating systems (0S) kernel. 


Man-in-the-middle (MITM An attack method where a malicious third party interposes between two other communicating parties and modifies the data 
attack) attack sent between them. 
Merchant-attended A deploymenit of a payment acceptance device or solution is merchant-attended where there is a merchant or merchant agent 


who is able to assist with, or provide oversight of, the paymenit process. 


Message authentication code | In cryptography, a small piece of information used to authenticate a message. 


(MAC) See Hash-based message authentication code (HMAC). 

Mobile device In the context of this Standard, see Commercial off-the-shelf (COTS) device. i 
Mobile Device Management A system for the administration of mobile devices such as smartphones, tablets, computers, laptops, and desktop computers. i 
(MDM) MDM solutions may be implemented in an MPoC Solution for the purposes of the secure distribution of MPoC Applications. 
M-of-N An M-of-N scheme is a key component or key share allocation scheme, where m is the number of shares or componenis i 


necessary to form the key, and n is the number of the total set of shares or componenis related to the key. Management of the 
shares or componenis should be sufficient to ensure that no subgroup of less than m persons can gain access to enough of the 
componenis to form the key. 


Monolithic Solution An MPocC Solution that is implemented without use of any other listed MPoC Products (such as an MPoC Software Product or 
Attestation and Monitoring Service provider). 


Mobile Payments on COTS All software that implemenits the base functionality reguired by the Mobile Payments on COTS solution, including the MPoC 


(MPoC) Software SDK functionality for accepting account data and PIN entry on COTS devices (where PIN entry is supported), API, attestation 
(also MPoC Software) componenis, and back-end functionality. The MPoC Software may also include the back-end payment processing environment 
or functions. 

MPoC Software vendor The Entity that is responsible for the development and maintenance of the MPoC Software. 
Mobile Payments on COTS The set of all COTS-based software deployed as part of the MPoC Solution that supports mobile payment acceptance, A&M i 
(MPoC) Application functionality, and protection of account data on a COTS device. An MPoC Application may optionally integrate the MPoC SDK 
(also MPoC Application) portion of a listed MPoC Software product, and/or be part of an MPoC Software Product. 
Mobile Payments on COTS The set of components and processes that supports mobile payment acceptance and protection of account data on a COTS i 
(MPoG) Solution device. At a minimum, the solution includes the MPoC Application, attestation system, and the back-end systems and 
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(also MPoC Solution) environmenis that perform attestation and monitoring. An MPoC Solution must implemenit the acceptance of chip-based 
payment cards (contact and/or contactless), in addition to any other payment acceptance types that if may support. 


Mobile Payments on COTS The subset of MPoC Software, that implements reguired functionality for the payment acceptance and attestation on the COTS 
(MPoC) SDK device, and secure communication with the back-end systems. 


(also MPoC SDK) 


MPoC Software vendor An entity developing, distributing, and supporting the MPoC Software. 

MPocC Solution provider An entity that develops, manages, and/or deploys MPoC Solutions. i 

MPoC Software Product The MPoC Software as validated and listed on the PCI SSC website. i 

Monitoring system Monitors and provisions security controls to detect, alert, and mitigate suspected or actual threats and attacks against the i 
MPoC Solution. 

Non-deterministic random A Random Number Generator that has access to an entropy source and (when working properly) produces output numbers (or i 

number generator (NRNG) bit strings) that have full entropy. Contrast with a Deterministic Random Number Generator (DRNG). 

Non-PTS approved MSR An MSR that has been validated against the reguirements in Appendix F of this standard. 

Obfuscation Protection applied to a process or data through increasing the complexity of interpreting that data. For the purposes of this 


standard, obfuscation refers to code obfuscation where computational processes have been applied to increase the complexity 
of a code set to reduce the ability to reverse-engineer that code. Determination of an acceptable level for obfuscation may 
involve assessment against the attack costing methodology of this standard. 


Offline paymenit transaction In an offline EMV transaction, the card and terminal communicate and use issuer-defined risk parameters that are set in the 
card to determine whether the transaction can be authorized. Offline transactions are used when terminals do not have online 
connectivity (€.g., at a ticket kiosk) or in countries where telecommunications costs are high. 


Operating system (0S) System software that manages the underlying hardware and software resources and provides common services for programs. 
Common OSs used ina COTS environment include, but are not limited to, Android and iOS implementations. 

OS store A digital distribution service operated by the COTS OS vendor or by the COTS device manufacturer used to distribute the i 
MPocC Application. 

Out-of-band Communication using a means independent of the primary communications means. i 

Payment-processing Back-end environment in which account data transferred from the MPoC Software is decrypted and/or processed. i 


environment 


PCI DSS The Data Security Standard published and maintained by the Payment Card Industry Security Standards Council. PCI DSS 
provides a baseline of technical and operational reguirements designed to protect account data. 
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Perfect forward secrecy Also known as “Forward Secrecy.” A protocol has Perfect Forward Secrecy if a compromise of long-term keys does not also 
compromise past session keys. 
Protection types The specific form of protection reguired for an assets, including one or more of confidentiality, integrity, and authentication. i 
Private key A a key used with a public-key cryptographic algorithm that is uniguely associated with an entity and is not made i 
public. 


In the case of an asymmetric signature system, the private key defines the signature transformation. In the case of an 
asymmetiric encipherment system, the private key defines the decipherment transformation. 


Provisioning / personalization | The process of ensuring that a specific instance of a system has the correct settings and unigue data to enable its operation. 


Public key A cryptographic key used with a public-key cryptographic algorithm that is uniguely associated with an entity and may be made 
public. 

In the case of an asymmetric signature system, the public key defines the verification transformation. In the case of an 
asymmetiric encipherment system, the public key defines the encipherment transformation. A key that is “publicly known” is not 
necessarily globally available. The key may only be available to all members of a pre-specified group. 


Public key cryptography See asymmetric encryption. 


PIN-processing environment | Back-end environment in which cardholder PINs are processed or translated for further processing. 


Random Number Generator The process of generating values with a high level of entropy and that satisfy various gualifications, using cryptographic and 
(RNG) hardware-based “noise” mechanisms. This results in a value in a set that has egual probability of being selected from the total 
population of possibilities, hence unpredictable. 


Replay attack A replay attack (also known as playback attack) is aform of network attack in which a valid data transmission is maliciously or 
fraudulently repeated or delayed. 


Rich execution environment Refers to an execution environment where COTS device resources are shared by OS applications. 


(REE) 

RSA Algorithm for public-key encryption described in 1977 by Ron Rivest, Adi Shamir, and Len Adleman at Massachusetts Institute i 
of Technology (MIT); letters RSA are the initials of their surnames. 

Secure boot See trusted boot. 


Secure Card Reader — PIN A physical card reader that has been assessed compliant to the PCI PTS SCRP Approval Class and is listed on the PTS listing 


(SCRP) website. 
Secure channel A physically or logically protected connection between two points. i 
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Term Definition 


Secure cryptographic device | A physically and logically protected hardware device that provides a secure set of cryptographic services. It includes the set of 
(SCD) hardware, firmware, software, or some combination thereof that implemenis cryptographic logic, cryptographic processes, or 
both, including cryptographic algorithms. Examples include ANSI X9.24 part 1 and ISO 13491. 


Secure element (SE) A tamper-resistant platform (typically a one-chip secure microconiroller) capable of hosting applications and their confidential 
and cryptographic data (e.g., key management) securely. 


Secure reading and Reguirements within the PCI PTS PO Standard, detailing testing for devices that protect account data. 
exchange of data (SRED) 


Security processor Within a COTS device, a security processor is a separate processor or co-processor with its own dedicated memory running 
separate OS, applications and data on these processors are not accessible by the COTS device's main OS. 


Sensitive authentication data | Security-related information used to authenticate cardholders and/or authorize payment card transactions. This information 
includes, but is not limited to, card validation verification codes/values, full track data (from magnetic stripe or eguivalent on a 
chip), PINs, and PIN blocks. 


Sensitive assets For the purposes of this standard, security assets include assets that reguire protection by, or be used to provide protection to, 
the MPoC Solution (e.g., cryptographic keys, or account data). 


Sensitive services A sensitive service is any service that may affeci the security of the overall system, as well as those functions that affect 
underlying processes that support the protection of assets—e.g., cryptographic keys and account data. Common examples are 
key management, modification, or update of attestation services, or remote component of contactless kernels (or other remote 
processing componenis) and cryptographic signing of assets to allow their authenticity to be verified. 


Service provider An entity responsible for deployment, operation, and management of the back-end monitoring; attestation; PIN processing; and 
account data processing environmenis. 

Software-protection Methods and implementations used to protect against the reverse-engineering and modification of software, including, but not i 

mechanisms limited to, hooking, rooting, emulation or debugging detection, verification, and validation of software. 

Software-protected A method used to obfuscate the execution of a cryptographic algorithm in software, including the protection of the i 

cryptography cryptographic key, with the goal of making determination of the key value computationally complex. 

Split knowledge A condition under which two or more entities separately have key componenis or key shares that individually convey no 


knowledge of the resultant cryptographic key. The information needed to perform a process such as key formation is split 
among two or more people. No individual has enough information to gain knowledge of any part of the actual key that is 


formed. 
Symmetric key Same symmetric key that is used for encryption is also used for decryption. Also known as “secret key.” 
Tamper detection A characteristic that provides evidence that an attack has been attempted. i 
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Tamper resistant A characteristic that provides passive protection against an attack. 

Tamper responsive A characteristic that provides an active response to the detection of an attack, thereby preventing a successful attack. i 

Trusted boot Also known as Verified Boot and Secure Boot. A cryptographic process where the bootloader verifies the integrity of all i 
componenis (e.g., kernel objects) loaded during the OS startup process, but prior to loading. 

Trusted execution A trusted execution environment provides hardware-based security features such as isolated execution environment for i 

environment (TEE) Trusted Applications. It isolates sensitive assets and code from the Rich Execution Environment (REE). 

Unattended A deployment of a payment acceptance device or solution is unattended where there is no merchant or merchant agent who İs i 

(also not merchant-attended) | able to assist with, or provide oversight of, the payment process. 

User interface (Ul) The set of the human-machine interfaces that allows for interaction between a person and a computerized system. i 

VTEE A virtualized trusted execution environment (TEE) that provides logical security features to isolate the execution environment i 
for Trusted Applications. A type of software-protection mechanism. 

White-box cryptography A iype of software-protected cryptography. 
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Scope of Mobile Payments on COTS Standard 


In traditional merchant-facing card-based payment scenarios, account data (e.g., PAN, PIN, etc.) is entered into a device specifically designed 
for protecting this data, such as a PCI PTS POJ approved PIN entry device (PED). The paymeni industry recognizes PEDs that have been 
independently tested and comply with detailed security reguirements developed by PCI to ensure the confidentiality, integrity, and availability 
of the PIN data. Traditional PEDs rely on hardware protections as the primary mechanisms to ensure the security of PIN data within the 
device. Merchants use traditional PEDs to support cardholder PIN acceptance. 


Figure 1: Traditional PIN Acceptance Solution Overview 
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Mobile payment acceptance enables the processing of paymeni transactions (©.g., using a smartphone or tablet that performs the functions of 
an electronic point-of-sale terminal). These solutions rely on a combination of mechanisms and security controls including, but not limited to, 
COTS device hardware, application software, and independent management and oversight of the entire process to ensure the security of the 
transaction and the cardholder verification data. 


Note: MPoC Solutions are intended for a merchant-attended environment only. 
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Mobile Payments on COTS—Payment Acceptance Channels and Cardholder Verification 
Methods 
This standard is designed to allow mobile paymenit solutions to support multiple paymenti-acceptance 


channels and cardholder verification methods. For example, one solution could support a COTS-native O Nofe: The solution deployment is 
NEC interface without PIN entry, while another solution could be designed to support COTS-native-NFC ( İmited to paymeni accepiance 


interfaces for contactless card entry with PIN, as well as also supporting PCI PTS SCRP devices. channels and consumer verification 
methods validated by the applicable 
Figure 2 shows the functional model of the solution that uses a software MPoC Application, with the PCI-recognized laboratory. 


option of additional hardware in the form of PCI PTS SCRP or Magnetic Stripe Reader (non-PTS 

approved MSR), for protecting account data. 

This standard defines the reguiremenis for assessmeni to validate candidate MPoC Products prior to it being listed on the PCI SSC website. 
For details on compliance programs outlining the use of listed MPoC Products, please refer to the relevant paymenit card brands. 


Figure 2: Mobile Payments on COTS Solution Showing Various CVM and Account Data Acceptance Options 
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The standard currently supports the following payment acceptance channels: 

» OCOTS-native NFC interface 

« OPCIPTS SCRP devices for contact, contactless, and MSR-based transactions 

" Non-PTS approved MSR devices validated through the MSR appendix of this standard 

" o Manually entered account data and cardholder verification methods: 

« OCOTS-nativePIN eniry 

" NoCVM 

»  CDCVM 
Support for any of the paymenit acceptance channels and/or CVMs described above is optional — the only reguirement is that an MPoC 
Solution, or MPoC Software Product, must support chip-based paymenis and at least one COTS-native method of eniry. As examples, an 


MPoC Solution may support COTS-native NFC and COTS-native PIN entry on the same device, it may support COTS-native NFC without 
PIN, or if may support account data entry through external readers only with COTS-native PIN. 


However, an MPoC Solution (or MPoC Software Product) may not support only MSR or manual eniry-based paymenis, or methods of account 
data entry performed exclusively through a PCI PTS SCRP, without any COTS-native account data entry methods. Individual transactions are 
exempi from this reguirement; any individual transaction may be MSR based, or exclusively use a PCI PTS SCRP — as long as the overall 
MPoC Solution (or MPoC Software Product if that is the MPoC Product under assessment) supports at least one COTS-native account data 
entry method. 


Where the MPoC Software supports any of the above methods it must meet and be validated to the applicable security reguirements 
described in the optional Modules in Domain 1: MPoC Software Core Reguiremenis. 


Mobile Payments on COTS—Security Model 


The security model of an MPoC Solution relies in large part (but not entirely) on mechanisms that support attestation and monitoring (to 
ensure the security mechanisms are intact and operational), detection (to notify when anomalies are preseni), and response (controls to alert 
and take action). The online nature of COTS devices provides opportunities to extend these capabilities to back-end monitoring systems. 


In addition, COTS devices that have specialized hardware-based security mechanisms, such as secure element (SE) or trusted execution 
environment, may use these mechanisms for secure storage or processing of cryptographic material or account data, or for functions 
supporting the attestation of the COTS device. 


There are, however, individual componenis of a software solution where there is limited control (e.g., the underlying COTS platform). Because 
ihese are COTS devices, there is an assumption that these componenis (e.g., COTS OS, configuration of hardware componenits of a phone, 
etc.) are unknown or untrusted. It must be assumed that an attacker has full access to the software that executes on any unknown or 
untrusted platform where that “software” may be a binary executable, interpreted bytecode, etc., as it is loaded onto the platform. Therefore, it 
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is important for the MPoC Software to provide inherent protections that complicate reverse engineering and tampering of the code execution 
flow on the COTS platforms to which it is deployed. This may include, but is not limited to, protections using obfuscation of the code, internal 
integrity checks for code and processing flows, encryption of code segmenis, etc. 


The architecture of an MPoC Solution relies on the following components that combine to provide for protection, attestation, detection, and 
response controls: 


A COTS device that is operated by the merchant to run the MPoC Application. The COTS device may have a TEE or secure element 
built-in, but this is not a reguirement. 


MPoC Application that resides on the COTS device and: 


Collects and passes attestation data about any attached hardware systems (such as a PCI PTS SCRP or non-PTS approved MSR), 
COTS platform, and MPoC Application to the attestation and monitoring back-end systems. 


Contains software protection mechanisms to maintain its own integrity against attack. 


Securely communicates account data (and other sensitive assets such as cardholder PINs, where these are supported and used) to 
back-end systems. 


(Optional) a secure Ul for entry of account data entry methods (such as PIN, PAN, or security codes), and encryption of this data. 
(Optional) a secure method for the entry and encryption of the account data acguired through COTS-native NFC read. 


Set of back-end systems that perform functions for the MPoC Solution such as: 


Attestation and monitoring systems process attestation data from the MPoC Application and enforce pre-established security policies 
as well as provision security controls to deteci, alert, and mitigate suspected or actual threats and attacks against the PCI PTS SCRP, 
MPoC Application, and the COTS device. 


Processing environment that receives encrypted account data, cardholder data and, if applicable, cardholder verification method (e.g., 
PIN data from the PCI PTS SCRP). 


(Optional) PCI PTS SCRP or non-PTS approved MSR device that supports the solution. The PCI PTS SCRP is SRED-enabled and 
connected to the COTS device. The PCI PTS SCRP optionally provides: 


Protection of account data 
Translation of PIN data for forward processing 
Secure random seeding and signing 
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MPoC SDKs and MPoC Applications 


All software within an MPoC Software produci, or software within a monolithic MPoC Solution that provides for the security of MPoC assets 
such as account data or cryptographic keys, must be assessed to Domain 1: MPoC Software Core Reguiremenis. This includes any 
applicable optional Modules corresponding with the supported payment acceptance channels and cardholder verification methods (such as 
COTS-native PIN entry, or COTS-native NFC). 


The MPoC Software is considered as two separate parts — the MPoC SDK (intended for integration into an MPoC Application) or complete 
MPoC Application itself, and the back-end software including the MPoC Attestation and Monitoring software. The MPoC SDK or MPoC 
Application execute on the COTS platform, although they may include remote execution componenis (such as a remote kernel). 


Any MPoC Application may optionally support APls that accept non-sensitive payment initiation data, such as an amount, from another 
“calling” application or function. This allows for an MPoC Solution to provide for paymenit initiation from applications outside of the scope of 
MPoC validation and listing — by providing an API through which an MPoC Application may receive non-sensitive payment initiation and 
response data (such as amouni). 


Therefore, there are three types of COTS software considered in an MPoC Solution: 
1. The MPoC SDK, which is designed to be integrated into an MPoC Application. 
The MPoC Application itself, which may or may not integrate an MPoC SDK. 


A 'calling application,” which can interface to APls exposed by the MPoC Application to initiate payment acceptance (not in scope of MPoC 
assessmeni). 


For any MPoC SDK, the following methods of integrating a set of pre-developed software as a component of an MPoC Solution have been 
considered in the creation of this standard: 


" oOSoftware that is designed and implemented as an entirely separate MPoC Application from a “calling application” executed in a 
completely separated execution environment (e.g., SE/TEE). 


" Software thatis an entirely separate MPoC Application executed in the same runtime environment as a calling application, 
invoked through OS APls (e.g., Intent on Android) by that calling application. 


" oSoftware thatis integrated into the MPoC Application as a pre-compiled code (e.g,, library). 


" Software thatis integrated into the MPoC Application as source code, which is compiled with the MPoC Application (this is nota 
permitted implementation for an MPoC Software produci). 


Due to the risk of modification of the MPoC Software, this standard does not allow for an MPoC SDK that is distributed and integrated as 
source code. 


Note: An MPoC Application may integrate up to two MPoC SDKS. 
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MPoC SDK Types and MPoC Application Implementations 
An MPoC SDK, where one exists, may be implemented as one of two types: 


« OAnlsolated MPoC SDK 
An Isolated MPoC SDK must provide for sufficient isolation of its memory space and be validated during the laboratory 
assessmeni that cleartext sensitive assets, such as account data or cryptographic keys, are not accessible by an MPoC 
Application that integrates that SDK. 


" A non-Isolated MPoC SDK. 
A non-Isolated MPoC SDK is an MPoC SDK that is unable to be validated to provide sufficient isolation to the cleartext sensitive 
assets from the MPoC Application. 


In each case, the validation of “sufficient isolation” is based on the laboratory assessment and costing framework outlined in the MPoC 
standard. Assets that are already sufficiently protected, e.g., through the use of cryptography or truncation (for PANs), are not considered in 
the determination of an Isolated or non-Isolated SDK. 


In all cases, an Isolated MPoC SDK cannot allow for sensitive cleartext data to be exposed to the MPoC Application, even if that functionality 
is optional or provided by some back-end function related to the MPoC Software. This is because the goal of an Isolated MPoC SDK is to 
preveni access to the sensitive assets — regardless of if this access is intended or not — so that even if the MPoC Application is compromised, 
the sensitive assets remain secure. There can be no APls or methods exposed that would allow for that compromised MPoC Application to 
gain access to those sensitive assets in cleartext. 


Note: lt is not sufficieni for an Isolated SDK to protect against reverse engineering only, e.g., through the use of white-box cryptography and 
code obfuscation alone. An Isolated SDK must prevent an MPoC Application from accessing cleartext sensitive assets, including during 
input/output through the physical interfaces of the COTS device (e.g., touch screen or COTS-native NFC). 


Based on these two types of MPoC SDK, the MPoC standard additionally supports the implementation of MPoC Applications in three different 
ways: 


1. Monolithic MPoC Applications that do not integrate an MPoC SDK from a listed MPoC Software Product. 
These types of MPoC Applications must be assessed to all relevant Domain 1 reguirements (only reguiremenis covering account data 
entry methods supported by the MPoC Application are assessed). Monolithic MPoC Applications are assessed to Section 2B of the 
MPoC standard. 


2. MPoC Applications that integrate a non-Isolating MPoC SDK. 
These types of MPoC Applications integrate an MPoC SDK, from a listed MPoC Software Product, that has not been validated to 
provide memory and cleartext asset isolation. MPoC Applications that integrate a non-Isolating MPoC SDK must be assessed to all 
reguiremenis of Domain 2 of the MPoC standard. 
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3. MPoC Applications that correctly integrate Isolating MPoC SDKs only. 
These types of MPoC Applications integrate an MPoC SDK, from a listed MPoC Software Product, that has been validated to provide 
memory and cleartexit asset isolation. MPoC Applications that correctly integrate only Isolating MPoC SDKs may be assessed to the 
Section 2A reguiremenis of Domain 2 of the MPoC standard only. 
If the MPoC Application does not correctly integrate an Isolating MPoC SDK, or the MPoC Application bypasses, modifies, or 
supplemenis the payment and/or security features of the Isolating MPoC SDK, then the MPoC Application must also be validated 
against the reguiremenis of Section 2B of Domain 2. 


An MPoC Application is permitted to integrate up to two MPoC SDKs (although this is a not a reguiremenit, and integration of one or no MPoC 
SDKS is also permitted). An MPoC Application that integrates a non-Isolating MPoC SDK is always assessed against all reguiremenits of 
Domain 2. Therefore, an MPoC Application that integrates two MPoC SDKs, where one is an Isolating SDK and one is a non-Isolating SDK, is 
reguired to be assessed against all reguirements of Domain 2 even though one of the MPoC SDKs it integrates is an Isolating SDK. 


A monolithic MPoC Application, or MPoC SDK of either type, may be implemented in part or whole outside the REE of the COTS device, e.g., 
as a “trustlet” executed within a TEE, which provides for the GUl and other interfaces necessary to provide the reguired account data inputs. 


An MPoC Application may be included as part of an MPoC Software Product as well as part of an MPoC Solution. For example, an MPoC 
Software product may be listed as providing an Isolating MPoC SDK, a non-Isolating MPoC SDK, and/or a complete MPoC Application (which 
may itself integrate an MPoC SDK from the same MPoC Software Product). 


Note: An MPocC Application listed as part of an MPoC Software Product must be developed by the MPoC Software vendor, and must not 
integrate the SDK of any other MPoC Software Product. 


Note: MPoC Applications listed as part of an MPoC Software Product must be integrated into a listed MPoC Solution before they can be used 
by merchanis. 


MPoC Applications that access account data are to be assessed against the reguirements of Domain 1, regardless of if they integrate an 
MPoC SDK (or either type) or not. 


An Isolated SDK may share some assets or configurations with the integrating MPoC Application, such as permissions with determine access 
to underiying COTS Platform systems, as long as those shared assets/configurations do not expose cleartexit sensitive assets. For example, 
permission to access a hardware-backed keystore that contains encryption keys used to proteci the sensitive assets could be shared between 
an Isolating MPoC SDK and the integrating MPoC Application, as long as those keys could not be used for decryption (as this would allow a 
compromised MPoC Application to remove the protection provided by the encryption processes). 
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Figure 3 illustrates the different types of MPoC Application and MPoC SDK. 
Figure 3: Examples of MPoC Application Implementations 
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MPoC Domain and Section Applicability 


An MPoC Solution may involve up to three types of Entities — an MPoC Solution provider, an MPoC Software vendor, and an MPoC 
Attestation and Monitoring Service provider. The MPoC reguirements applicable to each are illustrated below. An MPoC Solution that includes 
no other listed MPoC Products is always considered a monolithic MPoC Solution. 


The MPoC standard allows for an entity to take on more than one role in an MPoC Solution. For example, an MPoC Software vendor may 
choose to also take the role of an MPoC Solution provider while outsourcing the A&M operation to an MPoC Attestation and Monitoring 
Service provider. In this case, the MPoC Solution may consist of an MPoC Application that exposes payment APls for other applications to 
call, rather than an MPoC SDK to be integrated into new MPoC Applications (although this would also be possible). 


In another example, an MPoC Software vendor may take the role of an A&M Service provider themselves, operating their back-end software 
for different MPoC Solution providers. Other possible combinations also exist. However, in all cases, the reguiremenits that apply to that role 
will apply to any entity taking on that role. Only validated MPoC Solutions are permitted to be deployed for payment acceptance — it is not 
acceptable to have an MPoC Software Product performing payment acceptance without integration into an MPoC Solution, even if that MPoC 
Software Product is listed and includes an MPoC Application. 


A monolithic MPoC Solution does not use any other listed MPoC Products, and therefore must always use a monolithic MPoC Application, and 
an internally developed and operated Attestation and Monitoring system. If an entity wants to create an MPoC Solution with MPoC 
Applications that integrate an MPoC SDK, and/or that uses an outsourced Attestation and Monitoring Service, that MPoC Solution must be 
based on a listed MPoC Software Product. 


When reviewing the table below, consideration to the divide between the development and operational Domains of the MPoC standard is 
important. For example, MPoC Software is reguired to provide both an MPoC SDK component and/or MPoC Application (that executes on the 
COTS platform) and a back-end A&M component. The assessment of the technical and development aspecis of these MPoC Software 
componenis is performed in Domain 1. However, the operational aspecis of using these MPoC Software componenis is assessed in Domain 3 
and 4. 
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Table 2: MPoC Reguirements Applicability Matrix 


MPocC Solution Provider 


e : a z MPoC A&M 
: Monolithic MPoC Using Listed Using Listed z 
MPoC Software Core Reguirements Sollilon MPoC Software MPoC Software Service 


Software and Vendor Provider 
A&M Service 


Domain 1: 
Module 1A: CORE 


1A-1 Secure Software Reguiremenis 
1A-2 Random Numbers 

1A-3 Acceptable Cryptography 

1A-4 Key Management Design 

1A-5 Secure Channels 


1A-6 Third-Party APls 


Module 1B: MPoC SDK Software Protection 

1B-1 Software Security Mechanisms 

1B-2 Software-Protected Cryptography 

Module 1€: Aitestation and Monitoring Software 
1C-1 Coverage 

1C-2 Measurements/Detection 

1C-3 Response 

1C-4 Anti-Tampering 


1C-5 A&M Integration Guidance 
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MPoC Solution Provider 


MPoC A&M 
Software Service 
Vendor Provider 


Monolithic MPoC Using Listed Using Listed 
Solution MPoC Software MPoc 

Software and 

A&M Service 


MPoC Software Core Reguirements 


Module 1D: Secure Entry and Processing of Account Data 
1D-1 Account Data Entry and Encryption 
1D-2 Use of PCI PTS POl-approved Devices 
1D-3 Magnetic Stripe Data 

10-4 COTS-native NFC Interface 

1D-5 Manual Entry 

Module 1E: PIN Entry on COTS Device 
1E-1 COTS-native PIN Entry 

Module 1F: Offline Payment Transactions 
1F-1 Offline Payment Transactions 


1F-2 Offline Monitoring 


Module 1G: MPo€ Software Security Guidance 


1G-1 Security Guidance 


Domain 2: MPoC Application Integration 
Module 2A: MPo€C Software Integration 


2A-1 Secure MPoC SDK Integration and Usage v 


Module 2B: MPoC Application security 
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MPoC Solution Provider 


MPoC A&M 
Software Service 
Vendor Provider 


Monolithic MPoC Using Listed Using Listed 
MPoC Software Core Reguirements SDluilon MPoC Software MPoC 


Software and 
A&M Service 


Domain 3: Attestation and Monitoring 
Module 3A: MPoc€ Software Implementation Guide Compliance 


Module 3B: Baseline 


3B-1 COTS Platform Baseline & Vulnerability Management v | — v 


Module 3€: Attestation and Monitoring 


3C-1 Attestation and Monitoring Policy 
3C-2 Monitoring 

Module 3D: Operational Security 
3D-1 Operational Management 


Domain 4: MPoC Software Management 
Module 4A: Software Management 


4A-1 COTS Software Distribution and Updates 
4A-2 Key Management Operations 


4A-3 Penetration Testing and Vulnerability Management 
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MPoC Solution Provider 


EE i : : MPoC A&M 
Monolithic MPoC Using Listed Using Listed z 
MPoC Software Core Reguirements SDlUlON MPoC Software MPoC Software Service 


Software and Vendor Provider 
A&M Service 


Domain 5: MPoC Solution 
Module 5A: Third Party Management 


5A-1 Merchant Identification and Communication 
5A-2 Support for Multiple Entities in the Solution 


5A-3 Security of Back-end Systems 


Notes: 

1,2 These reguiremenis are to be assessed for MPoC Products that support these methods of account data presentment and processing. 
2 An MPoC Solution or MPoC Software Product must implement one or both of COTS-native NFC or COTS-native PIN eniry. 

3 This Module is only applicable if MPoC Applications integratingan MPoC SDK are supported. 


4 This Module is only applicable to MPoC Applications that integrate a non-Isolating MPoC SDK, or that are found to not correctly integrate an Isolating MPoC 
SDK. 


5 This Section only applies to an MPoC Software vendor when an aspect of the MPoC Software product is directiy distributed to merchants or end users. 


6 This Section only applies to an MPoC Software vendor when the MPoC Software vendor performs ongoing key management operations, such as updates to 
software protected cryptography. 
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Example MPoC Implementations 


This section provides some examples of how an MPoC Solution may be realized. The examples provided are non-exhaustive, and other types 
of implementations — with different combinations of listed MPoC Products and MPoC Applications — may be possible. 


Note: An MPocC Solution that relies on (one or more) Attestation and Monitoring Servicefs) needs to ensure the MPoC Applications it deploys 
are supported by those services. 


Monolithic MPoC Solution Examples 


A monolithic MPoC Solution is defined by the fact that it does not integrate or use any other listed MPoC Products. A monolithic MPoC 
Solution may include or use external card readers, such as a PCI PTS SCRP or non-PTS approved MSR. Monolithic MPoC Solutions are 
assessed to all Domains of the MPoC Standard, although some Modules/Sections/reguirements may not apply where these are scoped solely 
for the integration or assessmeni of different MPoC Product or account data eniry types. Refer to Section: MPoC Domain and Section 
Applicability above for details on the specific Modules and Sections that may apply. 


A monolithic MPoC Solution may implement multiple MPoC Applications, each with different account data entry methods and CVM support. 
For example, a monolithic MPoC Solution may have four MPoC Applications, split across two different operating systems. For each operating 
system there may be one MPoC Application that supports COTS-native NFC (with optional PIN as CVM), and one MPoC Application that 
supports card reading through a PCI PTS SCRP (with optional PIN as CVM). 


Alternatively, this example MPoC Solution may support only two MPoC Applications — with a single MPoC Application on each supported OS 
providing for both PCI PTS SCRP and COTS-native NFC reading (both with optional PIN as CVM). 


In all cases, a monolithic MPoC Solution will develop its own MPoC Applications and implement its own Attestation and Monitoring systems to 
support the MPoC Application(s) it deploys. 
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MPoC Solution implementing a single MPoC Software Product with an Attestation and Monitoring 
Service 


An MPo€ Solution that integrates or uses one or more listed MPoC Products is no longer considered a monolithic MPoC Solution. In this 
example, an MPoC Solution integrates a single MPoC Software Product — integrating the MPoC SDK into one or more MPoC Applications — 
and (in this example) also relies on the use of a listed Attestation and Monitoring Service provider who supports the same MPoC Software 
Product that includes the MPoC SDK that is used. 


In this example, the MPoC SDK being integrated supports an external non-PTS approved MSR and COTS-native NFC (with optional PIN 
support for the contactless payment channel). The MPoC Solution is deploying two MPoC Applications - one of the MPoC Applications 
implements both payment acceptance channels supported by the SDK (COTS-native NFC and non-PTS approved MSR), and one implemenis 
only the COTS-native NFC (with optional PIN) functions of the MPoC SDK. 


In this case, the MPoC Solution would not be assessed against Domain 1 or Domain 3, as it is not implementing its own software or attestation 
and monitoring systems as part of the core of the MPoC Solution (if the MPoC Solution were to implemeni its own attestation and monitoring 
systems, based on the MPoC Software Product used, Domain 3 assessment would be included). The MPoC Applications would be assessed 
against Domain 2, either Module 2A only (if the MPoC SDK is an Isolating SDK and is found to be correctly implemented), or both Modules 2A 
and 2B (if the MPoC SDK is non-Isolating). The MPoC Solution will also be assessed against the reguirements of Domain 4 and 5 of the 
MPoC Standard. 


The MPoC Software Product will have been assessed to Domain 1, and the Attestation and Monitoring Service to Domain 3, prior to listing of 
those MPoC Products. 


Some reguirements of Domain 4 may also have been assessed against the MPoC Software vendor and the Attestation and Monitoring 
Service provider, e.g., in the case the Entity manages their own software-protected cryptography implementation (with associated key 
management reguiremenis). However, even if this is the case, key management reguirements would remain in scope for the MPoC Solution 
as well (e.g., as they relate the management of PIN keys). 


An MPo€ Solution that integrates an MPoC Software Product may still implement monolithic MPoC Applications, but any such monolithic 
MPoC Application must be supported by its own Attestation and Monitoring systems (as the Attestation and Monitoring component of a listed 
MPoC Software Product will only support the MPoC SDK that is part of that MPoC Software Product). In such cases, the MPoC Solution will 
be assessed to Domain 1 and Domain 3 so that the security of the monolithic MPoC Application and attestation and monitoring systems can 
be validated. 
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MPocC Solution Implemented by MPoC Software Vendor 


An MPoC Software vendor may choose to implement their own MPoC Solution, potentially as a completely monolithic MPoC Solution, or 
based on their separately listed MPoC Software Product and MPoC Attestation and Monitoring Service. Assessment in this example would 
follow the examples given above, for either a monolithic MPoC Solution, or for an MPoC Solution implementing a single MPoC Software 
Product and Attestation and Monitoring Service. 


MPoC Solution Implementing Multiple MPoC Software Products with Multiple Attestation and 
Monitoring Services 


In another example, an MPoC Solution may integrate multiple MPoC Software Products, in conjunction with one or more Attestation and 
Monitoring Services. In this example, the MPoC Solution integrates two MPoC Software Products; one of these supports only COTS-native 
NEFC entry (with optional PIN for CVM) on a specific COTS OS (designed herein as OS(a)), and the other supports external reading of account 
data (using a PCI PTS SCRP) on two COTS OS's (the previousiy designed OS(a) and another COTS OS designed OS(b)) in addition to 
COTS-native NFC reading on OS(b) (both with optional PIN CVM). 


The example MPoC Solution deploys two MPoC Applications. The MPoC Application deployed on OS(b) integrates a single MPoC SDK. The 
MPoC Application deployed on OS(a) integrates two MPoC SDKs, one MPoC SDK to support COTS-native NFC (with optional PIN CVM) and 
ihe other MPoC SDK to support reading through the PCI PTS SCRP (with optional PIN CVM). 


The COTS-native PIN entry is separately managed by each MPoC SDK, as the PIN (or other sensitive assets) cannot be passed outside of 
ihe MPoC SDK boundary. Although this may lead to a different user experience for PIN entry for the MPoC Application deployed on OS(a), 
COTS-native PIN entry for any transaction must always be managed by the MPoC SDK that is used to read the paymeni card for that 
transaction. 


In this example MPoC Solution is not assessed to Domain 1 or Domain 3, as it relies on the MPoC Software that it integrates and does not 
implement any monolithic MPoC Applications. Each MPoC Application is assessed to Domain 2, with the MPoC Application that targets OS(/s) 
being assessed with respect to both of the MPoC SDKS it integrates. 


In the case where an MPoC Solution is integrating more than two MPoC Software Products, the use of more than two MPoC SDKs within any 
one MPoC Application is not permitted. 
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Relationship between This Standard and Other PCI Standards 


Various security reguiremenis in this standard are based on elemenis of, or share similarities with, other PCI standards, as follows: 


COTS device, attestation, and monitoring security controls to protect the security of paymeni transactions on COTS devices are 
consistent with PCI Software-Based PIN Entry on COTS (SPoG) and PCI Contactless Payments on COTS (CPoC). 


PO devices are approved per PCI PIN Transaction Security (PTS) Point of Interaction (PO) reguiremenis. 


HSMSs in the back-end environment used for PIN and account-data decryption, and related cryptographic-key operations reguire 
validation to PCI PTS HSM or FHIPS 140-2, or 140-3, Level 3 (or 4). 


Software used in the solution and software lifecycle practices are developed using best practices consistent with the PCI Software 
Security Framework (SSF). 


The back-end paymeni-processing environment is reguired to be PCI DSS compliant. 
The back-end PIN-processing environment is reguired to be PCI PIN Security compliant. 


The security reguiremenis for back-end attestation and monitoring environment are developed from PCI DSS DESV (where the 
back-end attestation and monitoring systems are sufficientiy isolated from any account data processing). 


Note: This standard does not supersede the reguiremenis of any other PCI standards (e.g., PCI Data Security Standard, PCI PIN Security 
Reguiremenis), nor do these reguiremenis constitute a recommendation from the Council or obligate merchanits, service providers, or financial 
institutions to purchase or deploy such solutions. As with all other PCI standards, any mandates, regulations, or rules regarding these 
reguiremenis are provided by the participating paymeni brands. 


Relationship between This Standard and PCI DSS 


There is an independent relationship between this standard and PCI DSS. A back-end attestation and monitoring environment could be 
part of a cardholder data environment (CDE) or be completely separate from any CDE. If a back-end attestation and monitoring 
environment contains account data, it is subject to PCI DSS DESV in accordance with payment brand compliance programs. 


If an entity has already applied PCI DSS to protect its back-end attestation and monitoring environment as part of its CDE, the entity 
may be able to leverage the results of its PCI DSS assessment to meet the security reguiremenis in this standard. For details, refer to 
Appendix A. 
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Relationship between This Standard and PCI PTS POl Standard 


The PCI PTS POLJ standard supports the use of secure hardware and Point of Interaction (PO) devices within the payment ecosystem. 
The use of PTS POJ devices in the solution to store, process, or transmit account data prevents exposure of sensitive assets on COTS 
devices and facilitates the principle of strong isolation of PIN and PAN. For more information about the PCI PTS POJ, including 
applicability to different types of hardware, refer to the PCI PTS POl Program Guide at www.pcisecuritystandards.org. 


Use of PCI PTS SCRP Devices 


A PCI PTS SCRP used with an MPoC Solution must be an approved PCI PTS device that is listed on the PCI SSC Approved Device 
website with an SCRP Approval Class. This class of devices may optionally support contact magnetic stripe reading functionality. When 
included with an MPoC Solution, a PCI PTS SCRP may be used for any method of card data presentmeni that it supports, including for 
ihe acceptance of contaciless payment cards. A PCI PTS SCRP may also be included when a COTS-native presentment method is 
used in place of one supported by the PCI PTS SCRP (e.g., a PCI PTS SCRP that supports contactless cards could be used with an 
MPoC Solution that uses COTS-native NFC acceptance instead). 


Use of Non-PTS Approved MSR 


When non-PTS approved MSR is supported by the solution, the tester must validate the standalone non-PTS approved MSR device 
against specific reguiremenis in Appendix F: MSR Security Reguiremenis that focuses on encryption of account data on the non-PTS 
approved MSR device. 


Note: PIN eniry is not permitted for any magnetic siripe-based transactions, regardless of the eniry method used (PCI PTS SCRP or 
non-PTS approved MSR). 


Relationship between This Standard and PCI SSC Software Standards 


PCI SSC supports the use of secure payment software within entities” cardholder data environmenis via the PCI Security Software 
Framework (SSF). The SSF consists of the Secure Software Standard and the Secure Software Lifecycle (Secure SLG) Standard. 
Software that is PCI SSC validated and listed provides assurance that the software has been developed using secure practices and has 
met a defined set of security reguirements. Entities that develop their own software are encouraged to refer to PCI SSC's security 
software standards and consider the reguiremenis therein as best practices to use in their development environmenis. Secure payment 
software implemented in a PCI DSS-compliant environment will help to minimize the potential for security breaches leading to 
compromises of account data and the damaging fraud resulting from these breaches. 


The MPoC standard reguires developers of MPoC Software (or the software componenis of a monolithic MPoC Solution) are assessed 
against the reguiremenis of the PCI Secure SLC standard. It is not a reguirement that these entities are listed on the PCI website as 
meeting these reguiremenis. 
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Relationship between This Standard and PCI PIN Standard 


MPoC Solutions may be used for the acceptance of cardholder PINs. The security of the key management and cryptographic processes 
used to handle customer PINs are covered by the PCI PIN standard, and therefore this standard reguires compliance to the PCI PIN 
reguiremenis for any back-end systems involved in PIN processing. Reguirement 1 of the PCI PIN standard outlines a need to have all 
PIN acceptance devices approved to PCI PTS and does not need to be assessed as compliant for the MPoC implementation. 


Relationship between This Standard and PCI SPoC Standard and PCI CPoC Standard 


The MPo€ standard incorporates and builds upon many of the concepts and reguirements founded in the PCI SPoC and PCI CPoC 
standards. However, the MPoC standard does not supersede or replace these other mobile standards. For details of any migration path 
from an existing SPoC or CPoC Solution to the listing of an MPoC Solution, refer to the MPoC Program Guide. 
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Security Reguiremenis for Mobile Payments on COTS Solution 


Objective-Based Approach to Reguirements 


The security and test reguiremenits of this standard address known attack scenarios at the time when the standard was published. Any entity 
responsible for some component of an overall MPoC Solution has ongoing responsibility to proactively perform risk assessmenis to identify 
potential security flaws in transaction scenarios that were introduced by changes in technology or by the identification of new threats and 
vulnerabilities. 


For an objective-based approach to be successful, entities are expected to possess a robusi risk-managemeni practice as an integral part of 
iheir “bUsiness-as-usual” operational process. While this approach provides the entities with the flexibility to implement security controls based 
on identified risk, the entity needs to be able to demonstrate how the implemented controls are supported by the results of its risk-identification 
and risk-managemenit practices. Without a robust risk-managemenit practice and evidence to support risk-based decision making, adherence 
to the reguiremenis in this standard may be difficult to validate. 


If security reguirements do not define a specific level, rigor, or freguency for periodic or recurring activities (e.g., bhe maximum period in which 
an entity İs reguired to release a security update to fix a known vulnerability), the entity may define the level of rigor or freguency that is 
appropriate. The rigor and freguency defined by the entity must be supported by documented risk assessments and the resultant risk- 
management decisions. The entity is expected to be able to demonsirate that its implementation provides ongoing assurance that the security 
controls or security activities are effective and meet all applicable reguiremenis. 


Reguirement Freguency 


Certain security and test reguiremenis have been established with specific timeframes for activities that must be performed consistently via a 
regularly scheduled and repeatable process. The intent is that the activity is performed at an interval as close to that timeframe as possible 
without exceeding it. The entity has the discretion to perform an activity more often than specified (e.g., performing an activity monthly where 
ihe security reguirement specifies it be performed every three months). 
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Table 3. Security Reguirement Timeframes 


Timeframes Descriptions and Examples 
Daily Every day of the year (not only on business days). 
i Weekly At least once every seven days. i 
i Monthly At least once every 30 to 31 days, or on the ni" day of the month. i 


i Every three months (“guarteriy”) | At least once every 90 to 92 days, or on the n" day of each third month. 


i Every six months At least once every 180 to 184 days, or on the ni" day of each sixth month. 
i Every 12 months (“annually”) At least once every 365 (or 366 for leap years) days or on the same date every year. 
i Periodically Freguency of occurrence is at the discretion of the entity and is documented and supported by the risk assessment. The 


entity must demonstrate that the freguency is appropriate for the activity to be effective and to meet the intent of the 
reguiremeni. 


i Immediately Without delay. In real time or near real time. 
Promptly As soon as reasonabiy possible. 
Significant change There are certain reguiremenis for which performance is specified upon a significant change in the MPoC Software, 


backend, or the solution. While what constitutes a significant change is highly dependent on the configuration of a given 
environment, supported COTS OSs and COTS devices, MPoC Software architecture, etc., each of the following activities, at 
a minimum, has potential impacts on the security of the solution and must be considered as a significant change in the 
context of related reguiremenis: 


» Changesto hardware-based or software-based security control to protect cryptographic materials 


» Anychangestothe underlying supporting infrastructure of the solution (including, but not limited to, changes to 
attestation, and monitoring system) 

» Any changes to third-pariy vendors/service providers or services provided that support the solution or meet security 
reguiremenis on behalf of the MPoC Solution provider (e.g., identification of security vulnerabilities in an unsupported 
OS) 


For other reguiremenis, where the standard does not define a minimum freguency for recurring activities but instead allows for the reguirement 
to be met “periodically,” the entity is expected to define the freguency as appropriate for its business. 
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Reguiremenis Structure 


The security reguiremenis defined within this standard are presented in the following format: 


Security Objective. Identifies the high-level security objective that the entity is reguired to meet. Security objectives are broadiy 
stated to enable entities flexibility in determining the best methods to achieve the stated security objective. However, it is expected 
that the entity produces clear and unambiguous evidence to show that the chosen methods are appropriate, sufficient, and 
properiy implemented to satisfy the security objective. Below the security objective, additional information has been provided to 
help both entities and laboratories understand the intent behind the security objective. 


Security Reguiremenits. Specific security controls or activities that must be implemented by the entity to support the overarching 
security objective. 


Test Reguiremenis. Describe the expected testing activities to be performed by the laboratory to validate whether an entity has 
met a particular security reguirement. The test reguiremenis are intended to provide both the entity and the laboratory with a 
common understanding of the assessment activities to be performed. The specific methods and items examined, and the 
personnel interviewed, are reguired to be appropriate for the security objective and associated reguiremenis being assessed and 
for each entity's particular implementation. 


Guidance. Additional information to help entities and laboratories understand the intent of each reguirement. The guidance may 
also include best practices that should be considered as well as examples of controls or methods that, when properly 
implemented, may meet the intent of the reguiremenit. This guidance is not intended to preclude other methods that an entity may 
use to meet a reguiremeni, nor does it replace or extend the reguiremenis to which it refers. 


Testing Methods 


Entities are expected to produce evidence that they have satisfied the security reguirements defined in this document. The test reguiremenits 
for each security reguirement describe the activities to be performed by the tester to demonsirate that the entity has met that security 
reguiremeni. Where the tester finds it necessary to develop alternative tests, they must provide appropriate justification for their use. Test 
reguiremenis typicaliy include the following activities: 


Examination. I he tester critically evaluates evidence. Common examples of evidence include software design and architecture 
documenis (electronic or physical), source code, configuration, and metadata files, bug tracking data, and other output from 
software-development systems, and security-testing results. The choice of which evidence may be used to meet an examination 
reguiremeni is deliberately left open for the tester to determine. However, it is a reguiremeni of this standard that the source code 
of the MPoC Software and MPoC Application is made available for review as part of the assessment. It is not acceptable for an 
evaluation report to be provided where no source code was examined or used in the process of performing the testing. 

Where this standard uses the term “document,” this is not reguired to be a formal physical document. Other types of managing 
information may be acceptable if they contain the reguired information and have the reguired utility of purpose. 
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Testing. The tester evaluates the solution code or the operation of the solution software using a variety of security-testing tools 
and technigues. Examples of such tools and technigues include the use of automated static analysis security testing (SAST), 
dynamic analysis security testing (DAST), interactive application security testing (lAST), and software composition analysis (SCA) 
tools. Manual technigues, such as manual code reviews, penetration testing, side-channel attacks, fault injection, and memory 
scraping, may need to also be considered. 


Observation. The tester watches an action or views something in the environment. Examples of observation subjects include 
personnel performing tasks or processes, software or system componenis performing a function or responding to input, system 
configurations/settings, environmental conditions, and physical controls. Observation may include the performance of “tests,” so 
that the output of those tests may be observed, potentially under changing conditions as the input is manipulated by the tester or 
other systems. 


An “observation” test process generally differs from a “testing” test process in that it involves some aspect of the normal operation of the 
system under test rather than testing of some subsystem or subfunction. For example, a process involving validation of protections 
against Man-in-the-Middle attacks through manipulation of a TLS connection from a functioning system would be “observation.” Side- 
channel analysis of the cryptography implement during the TLS process would be performed as part of “testing.” 


Interview. The tester converses with individual personnel. The purpose of interviews includes determining how an activity İs 
performed, whether an activity is performed as defined, and whether personnel have particular knowledge or understanding of 
applicable policies, processes, responsibilities, and concepis. 


Document. The tester provides details or information in the evaluation report, which may be used in the same or subseguent 
testing reguiremenis. 


The test reguirements provide both entities and testers with a common understanding of the validation activities to be performed. The specific 
items or processes to be examined or observed and personnel to be interviewed are reguired to be appropriate for the security reguirement 
being validated and for each entity's structure, operations and business practices. For example, it is expected that not every item of 
information will be contained in a formal document, and not every interview will be conducted in person. It is at the discretion of the tester to 
determine the appropriateness or adeguacy of the evidence provided by the entity to support each security reguirement. Where bullets are 
specified in a security reguiremeni or test reguiremeni, each bullet is expected to be tested as part of the validation. 


When documenting the assessment results, the tester identifies the testing activities performed and the result of each activity. While it is 
expected that the tester will perform all the test reguiremenis for each security reguiremeni, it may also be possible for a security reguirement 
to be validated using different or additional testing methods. In such cases, the tester is expected to document why alternative testing methods 
were used that differed from those identified in this document, and how those methods provided at least the same level of assurance as the 


documented testing methods. Where terms such as “periodic, 


appropriate,” and “reasonable” are used in the test reguiremeni, it is the 


entity's responsibility to define and defend its decisions regarding the freguency, robustness, and maturity of the implemented controls or 


PrOCESSES. 
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Security Objective and Assets 


This standard sets forward various security control objectives for the purposes of protecting assets. Within the context of this standard, assets 
are elemenis of the MPoC Solution that are security sensitive or are used to provide security to other security-sensitive elements. Examples of 
assets include data such as account data, cardholder PINS, certificates, and cryptographic keys. Software may also be considered an assets if 
ihe correct operation of that software is reguired to provide security protection to other data asseis. 


Sensitive assets are a sub-set of the asset class that reguire confidentiality protections. 


The specific assets used in a solution are expected to be unigue to how that solution operates, and therefore a comprehensive list is reguired 
to be developed as part of the evaluation of any MPoC Solution. 


The security controls reguired to protect payment information depend on the type of payment acceptance channels and cardholder verification 
methods supported by the MPoC Software. All MPoC Software is reguired to meet the security objective, reguiremenis, and test reguiremenis 
in the Core Module. The objective of these security reguiremenis is to ensure the integrity of the COTS device, and to reasonabiy ensure that 
ihe solutions provide adeguate security mechanisms, controls, and mitigations to protect the cardholder's account data and other assets such 
as cryptographic keys. These reguiremenis assist with protection from unauthorized disclosure, modification, or misuse by restricting the 
available attack surface and making it cost prohibitive to attack. 


It is recognized that an attacker may have other objectives, such as self-promotion or nation-state attack, and may expend more resources to 
circumvent established controls than is warranted by the direct financial rewards. 


For the COTS platform components, the objective of these security reguiremenis İs to provide reasonable assurance that these componenis 
are kepi up to date and have not been tampered with. 


The following table provides examples of MPoC Software assets and lists the protection reguired. This protection may be confidentiality (GC), 
integrity (1), and integrity with the addition of auditability and authentication (14). This table does not purport to be an exhaustive list of all 
sensitive assets that may be stored or processed by an MPoC Solution. assets not identified in this table may exist and may reguire 
protection. 
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Table 4: Examples of MPoC Software Assets 


Data Element Desgrlbilol Protection 
Type p Type 
Account data Account data consists of cardholder data and/or sensitive authentication data. C&l 
Cardholder Method used to verify the identity and intent of the cardholder performing the transaction. Examples C&lı 
Verification Method | include PIN or signature. Use of a CVM is not mandated by this standard and some transactions may 
(CVM) use no CVM. 
Attestation Data Information collected from the COTS device for the purposes of validating it is in an uncompromised C&l4 
and secure state, suitable for performing MPoC transactions. 
Contactless Kernel Includes split contactless kernel implementations. 1 
Cryptographic Cryptographic keys and related parameters (static and ephemeral) used to protect other sensitive C&lı 
Material assets such as account data, PINS, etc., as well as establish secure channel and signing attestation 
data. Note: Public cryptographic keys do not need Confidentiality protection. 
MPoC Software A compiled software or a library distributed for use with the MPoC Application. 1 
SDK 
MPoC Software The source code of the MPoC Software used as part of the overall MPoC Solution. Includes code C&lı 
Source Code that may be present on the COTS device, as well as code that may be used on the back-end 
systems. MPoC Software source code may be present 
SCRP Enablement Cryptographically authenticatable token used to enable transaction processing on a PCI PTS SCRP. C&lı 
Token 
Provisioning/secret Upon installation, MPoC Applications must be provisioned with secret data, to bind the MPoC C&lı 
identification data Software to the COTS platform, and cryptographic keys to secure the sensitive assets they process. 
This assets class is not intended to include merchant ID data used for transaction processing or other 
non-secret data. 
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Domain 1: MPoC Software Core Reguirements 


The security reguiremenits in this Domain apply to the individual components and processes that make up the MPoC Software or the 
eguivaleni areas of software provided by an MPoC Solution where a separately listed MPoC Software is not used. Wherever the terms MPoC 
Software or MPoC SDK are used within this Domain, reguirements apply egually to the eguivalent areas of an MPoC Solution that does not 
use listed MPoC Software. 


The functional reguiremenis of the MPoC Software can be further organized into the following components assessed under this Domain: 


" A software application or a library that implements paymenit acceptance and optional supported cardholder verification methods 
and/or may influence the security of payment data processing on the COTS device (the MPoC SDK or a monolithic MPoC 
Application). This software may be executed, in part or as a whole, on the COTS device itself or executed remotely and rendered 
on the COTS device through other means. 


" The back-end attestation and monitoring systems that cannot be entirely (logically) accessed from the merchant environment and 
that must be capable of being regularly/rapidiy updated to respond to new threats and to apply changes or updates to the 
solutions. 


« An optional API provided by the MPoC SDK that allows other third-party developers to interface with the MPoC Solution. 


" All contactless kernels used in the MPoC Software, regardless of their implementation within MPoC SDK, residing on the COTS 
device or implemented as a remote component of a contaciless kernel (e.g., cloud-based). 


Optional Modules within Domain 1 include additional security objectives to protect sensitive assets associated with specific paymeni- 
acceptance channels and cardholder verification methods such as following: 


s PIN Entryon COTS device. İncludes security reguiremenis to ensure the integrity of the PIN entry process on the COTS device. 
These reguirements apply only to MPoC Software that supports PIN CVM. 


« o Offline Payment Transactions. Includes reguiremenis to ensure that support for Offline Payment processing is performed 
securely. 


" oOSecure Entry and Processing of Account Data. Although not an optional Module, this includes optional Sections that provides 
security reguiremenis for account data entry methods, such as COTS-native NFC, manual eniry, or to ensure secure pairing with 
a PCI PTS SCRP, or non-PTS-approved MSR. 


It is expected that the attestation system monitoring systems will integrate both local and remote features to allow for the identification of new 
iypes of attacks, rapid response, and deploymenit of updated mitigations against such threats. When MPoC Software relies on COTS 
hardware-based security controls or features, such as SE or TERE, these must be included in the scope of evaluation and evaluated against the 
applicable security reguiremeni in this Domain. 


The test reguirements of Domain 1 apply to the software used in monolithic MPoC Solutions, as well as software that is designed for 
submission and listing as a separate MPoC Software Product. 
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Module 1A: CORE 


These reguiremenis are applicable to the MPoC Software. This includes the software executed on the COTS device, any Trusted Applications 
(TA) used, and the back-end systems software (processing, monitoring, and attestation). 


14-1 Secure Software Reguiremenis 


Software is to be developed and maintained according to a defined software-security development and lifecycle process. Software 
developers reguire knowledge to address software vulnerabilities and emerging risks. 


Development of secure software reguires knowledge of common attack technigues and vulnerabilities. These vulnerabilities can change 
over time; therefore, a continuous process to inform software developers about these changes is vital. It is not sufficient to confirm that 
ihe developers have been provided with documentation, books, and/or training on secure software development. There needs to be 
auditable confirmation that developers have knowledge of common vulnerabilities in the language and environment in which they 


develop software. 


To facilitate reliable and accurate paymenit transactions, the systems and software used as part of the paymeni-transaction flow must be 
designed, developed, and maintained in a way that protects the integrity of paymeni transactions and the confidentiality of all sensitive 
assets stored, processed, or transmitted in association with paymeni transactions. 


Security Reguiremenis 


| Test Reguiremenis 


| Guidance 


Objective: Vulnerabilities in software that may pose a security risk to MPoC Software and A&M back-end assets are prevented. 


1A-1.1 MPoC Software must be either: 


» (O Developedbya PCI Secure Software 
Lifecycle (SLC) Gualified Software 
Vendor, or 


»e (o Comply with all reguirements in 
Appendix D: Software Security 
Lifecycle Reguiremenis. 


1A-1.1.a When the software is developed by a PCI 
Secure SI C-approved software vendor, the tester 
must confirm through examination that the entity İs 
listed on the PCI website and it is valid at the time of 
evaluation (e.g., the listing has not expired). 


The MPoC Software needs to be developed and 
maintained in accordance with secure coding standards 
and industry best practices to reduce the risk of 
vulnerabilities being introduced that result from poor 
coding technigues. 


1A-1.1.b When the software is not developed by a 
PCI Secure SLC-approved software vendor, the 
tester must confirm through examination, 
observation, and interview that the reguiremenis in 
Appendix D: Software Security Lifecycle 
Reguiremenis are met. 


Knowledge of industry software development standards 
and best practices provides information on current 
exploits and trends. 


PCI SSC publishes additional guidance, from time to time, 
on besi practice for the assessment of environmenis and 
processes. This guidance may allow for some aspecis of 
an assessmenis to be performed remotely. 
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Security Reguiremenis 


1A-1.2 A public security-flaw-reporting 
program must be implemented to 
encourage the finding and reporting of 
vulnerabilities. 


Test Reguiremenis 


1A-1.2.a The tester must confirm through 
examination that a vulnerability-reporting program 
exists for the system, and there is evidence of 
accepting and remediating security vulnerabilities 
found through this program. 


1A-1.2.b For any vulnerabilities have been reported 
through the security flaw reporting program the 
tester must confirm through examination that any 
such vulnerabilities are processed through the 
vendor risk-and-update process and patched 
accordingiy. 


1A-1.3 A penetration test must be 
performed on the MPoC Software prior to 
initial assessment and at least once per 
year thereafter. 


1A-1.3.a The tester must confirm through 
examination that a penetration test has been 
performed on the MPoC Software prior to initial 
assessment and at least annualiy thereafter. 
Penetration testing reports must be examined to 
confirm that the scope covers all aspects of the 
MPoC Software, including all types of platforms 
supported, and that vulnerabilities found during the 
penetration testing have been remediated or are 
mitigated through other protections provided by the 
solution. 


Guidance 


Penetration testing and vulnerability management 
processes are expected to be part of ihe MPoC Software 
vendor's secure software lifecycle process. This 
reguiremenit confirms the scope and efficacy of the 
penetration testing as it is applied to the MPoC Software 
specifically. 

Penetration tests need to be performed by suitabiy skilled 
resources and may be performed by resources internal to 
the MPoC Solution provider if such resources exist. When 
penetration testing is performed by internal resources, the 
people performing the testing need to be separate from 
those who have been involved in the development of the 
MPoC Software. Skills expected from the resources used 
for penetration testing include: 


» An understanding of EMV protocols and payment 
processing 


»e o Skills and experience with mobile security and 
communications protocols 


» Aclear history of penetration testing experience 


Results from annual penetration testing may not exist for 
newiy developed MPoC Software products, but need to 
be provided for any review performed after the first year 
of validation. However, an initial penetration testing report 
is reguired to be available prior to the listing of the MPoC 
Software or the MPoC Solution (for monolithic solutions). 


Penetration testing may be performed by the same entity 
that performs the MPoC evaluation; however, the MPoC 
evaluation itself cannot be considered a penetration test 
to meet this reguirement. A separate testing and reporting 
process must be implemented for this penetration test. 
This may reguire that the target of the penetration test 
(such as an MPoC Software product) is provided with a 
test harness to facilitate the operation of the software 
during the penetration testing. 


Any vulnerabilities identified in penetration testing must 
be considered during attack costings. 
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Security Reguiremenis 


1A-1.4 The MPoC Software A&M 
component must meet the security 
reguirements described in PCI Secure 
Software Standard. 


Test Reguiremenis 


1A-1.4.a Where an existing validation and listing of 
the MPoC Software A&M component to the PCI 
Software Security Standard exists, the tester must 
confirm through examination and observation that 
the assessment scope and listing are correci, 
complete, and current. The tester must cite the 
listing number and version from the PCI website 
listing. 


1A-1.4.b Where an existing validation and listing of 
the MPoC Software A&M component to the PCI 
Software Security Standard does not exist, the 
tester must confirm through examination, testing, 
observation, and interview that all software 
developed by the entity meets the security test 
reguiremenis outlined in the PCI Secure Software 
Standard, including applicable modules of that 
standard. 


Guidance 


Security controls to protect the integrity and the 
confidentiality of the sensitive assets stored, processed, 
or transmitted by the MPoC Software are vital for any 
MPoC Solution. 


There is no one-size-fits-all method to software security. 
As aresult, entities need flexibility to determine the 
software security controls and features most appropriate 
to address their specific business and software risks. As 
such, it is reguired that entities possess a robusi risk- 
management practice as an integral part of their 
business-as-usual operational processes and be able to 
demonstrate how the implemented security controls are 
supported by the results of their risk-management 
practices. 


The MPoC Software may implement some software that 
is not directly under the control of the MPoC Software 
developer. In such circumstances, the source code may 
not be available for examination. The tester is expected to 
use other methods to confirm that security reguiremenits 
are met by this software. 


It is expected that not all reguirements of the PCI Secure 
Software Standard will be in scope for an assessment of 
MPoC Software. The tester is expected to leverage their 
understanding of the software to scope the relevant 
reguiremenis as applicable for the current assessmenit. 


Depending on the assets handled by the MPoC Software 
(e.g., account data) and the underiying technologies (e.g., 
Internet technologies, protocols, and languages), 
additional modules outlined in the PCI Secure Software 
Standard may be applicable. For example, Module A of 
the PCI Secure Software Standard covers the 
reguiremenis for software providing protection to account 
data. 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0 
© 2022 PCI Security Standards Council, LLC. All rights reserved. 


November 2022 
Page 48 


» Security Li 
Standards Council 


Security Reguiremenis Test Reguiremenis Guidance 
1A-1.5 The MPoC Software must 1A-1.5.a The tester must confirm through The MPoC standard is intended for use with solutions that 
implement chip-based payment examination and observation that the MPoC use COTS-native interfaces for the acceptance of chip- 
acceptance utilizing the COTS platform Software implemenits at a minimum (both of the based paymeni transactions, or cardholder verification 
for the entry of at least one form of following): methods (such as a PIN). Solutions that rely entirely on 


account data. non-COTS devices, such as a PCI PTS device, for the 


contact or contactless chip (through COTS- acceptance of account data, and do not provide for any 
native interfaces, or through use of an external || COTS-native acceptance of account data or PIN data, are 
PCI PTS SCRP). not intended for assessmeni under this standard. 


e — COTS-native interfaces for the input atleast For example, solutions that support only magnetic stripe 
one of either contactless chip, or cardholder cards, only manual FAN entry, or only uses ihe COTS 
PIN. device as a communication system for an attached PCI 

PTS device that performs the acceptance of card and 

PIN, are not able to be considered for validation and 

listing under the PCI MPoC standard. 


Magnetic stripe card and manual PAN entry transactions 
may be supported as optional payment channels with 
solutions that meet this reguiremenit to support chip- 
based transactions. 


» (Payment acceptance for atleast one of either 
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14-2 Random Numbers 


Random numbers are relied upon by many security processes and secure communications methods. Generation of random numbers 
with insufficient entropy has been the cause of many high-profile vulnerabilities. This makes the guality of the random numbers 
generated by the MPoC solution vital. Random numbers are to be generated using a process that ensures sufficient entropy (e.g., as 
defined in NS7 SP800-22) and lack of statistical correlation. 


Any random numbers used for security purposes must be generated using a secure method, such as a DRNG seeded from a value that 
comes from a trusted source. A COTS device that has a TEE or SE evaluated as a random number generation source directly can be 
used as a source of entropy. Otherwise, a DRNG must be used, seeded from an external trusted source such as a PCI PTS SCRP ora 
back-end system such as an HSM, in addition to entropy from the COTS device itself. Combining these different eniropy sources 
ensures that even if one İs compromised it does not automaticaliy invalidate the security of the random number generation process asa 
whole. 


This applies to all components and parts of the MPoC Software where random numbers are reguired to be generated for security 
functions. Random numbers that are not relied upon directly for security of the account data or attestation data, such as random values 
used in TLS sessions where the data being transmitted is otherwise protected using application-level cryptography, are exempit from this 
Section. 


The MPoC SDK should maintain an entropy “pool” that is updated regularly from the trusted source and other sources on the COTS 
platform. This pool data is sensitive and should be protected. 
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Objective: Random numbers are sufficiently unpredictable. 


1A-2.1 Software development 1A-2.1.a The tester must confirm through This reguirement applies to all MPoC Software regardless 

documentation must provide details about | examination that the software-development of where it is executed (i.e., this reguirement applies to 

how the MPoC Software generates processes and practices used, with respect to the both back-end and MPoC SDK software). 

secure random numbers, as reguired, on | generation of random numbers, include the reguired | Random number generation often sets the security 

all deployed platforms. information and are consistent with the tester's baseline upon which other security conirols rely. This may 
understanding of the MPoC Software. include the generation of padding data for use in 
Information maintained for random number certificates, key bundles, and EMV flows as well as the 
generation method must include at a minimum: generation of cryptographic keys. 


e The generation and origin of random numbers. Random generator attacks by malicious users exploit 
weak random number implementations and have been 

e e SADECEE Seir Me yale meç the cause of several Kid peohle vulnerabilities. Therefore, 

e» o The seeding period. the guality of the random numbers generated by the 

» (Details of any DRNG algorithms implemented. | Solution is vital. 

The information is reguired to cover all uses of random 

numbers, including, at a minimum, the entropy sources 

for the attestation system and key-generation processes. 


The information provided needs to inform the use of all 
random number generation methods within the software. 
The remaining reguirements in this Section describe the 
testing reguired to validate that the implementation is 
produced in line with the rules of the software- 
development process. 


Entropy supplied by any random number generation 
system should be sufficient for the use cases to which it İS 
applied. For example, a random number used to generate 
a new key should provide enitropy at least egual to that 
key value. For details on minimum cryptographic key 
strengths and other items of cryptography, refer to 
Appendix C. 
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1A-2.2 The MPoC Software must use an 
assessed source for the generation of 
random numbers where the security of 
assets reguires the use of random 
numbers. 


Test Reguiremenis 


1A-2.2.a The tester must confirm through 
examination that, where the security of assets 
reguires the use of random numbers, an assessed 
Random Number Generator (RNG) is used. 


1A-2.2.b The tester must confirm, through testing 
against industry-recognized test suites such as 
NIST SP800-22 or AlS-31, that any Random 
Number Generator (RNG)s used for security 
services are fit for this purpose. 


Note: For configuration and use of the NIST SP800- 
22 STS tool, refer to Appendix F. 


Guidance 


This reguirement applies to all MPoC Software regardless 
of where it is executed (i.e., this reguirement applies to 
both back-end and MPoC SDK software). 


Examples of situations where random numbers may be 
reguired to secure account data include the generation of 
cryptographic keys, padding prior to encryption of account 
or PIN data, or security controls such as attestation 
functions. The EMV Unpredictable Number (UN) used by 
a paymeni kernel is not included in the scope of this 
reguirement. However, where a paymeni kernel reguires 
entropy for other security purposes, these random 
numbers are in scope of this reguiremenit. 


It is reguired that account data and attestation data are 
protected with cryptographic controls. Such controls often 
depend on the guality of random numbers to maintain the 
designed security levels. 


The Random Number Generator (RNG) used by the 
MPoC Software is reguired to be tested for fitness of 
purpose against indusitry-recognized test suites such as 
NIST SP800-22 or AlS 31. 


A trusted execution environment or secure element that 
has an existing assessment confirming its suitability for 
the generation of cryptographically strong random 
numbers may be used where present in supported 
platforms. Where such random number generation 
hardware is not present or cannot be relied upon to be 
present on all supported platforms, a software DRNG is 
reguired. 


Previous assessments that can be used to validate the 
suitability of a trusted execution environment/secure 
element include common criteria, EMVCo, and other 
industry standard assessmenis. 
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1A-2.3 When not using a hardware based | 1A-2.3.a The tester must confirm through DRNG algoritams used by the MPoC SDK are reguired to 

true Random Number Generator (RNG), examination that, where a hardware based true be secure algoritams and known international standards 

the MPoC SDK must implemeni its own Random Number Generator (RNG) is not directiy suitable for cryptography use as specified in Appendix C: 

secure DRNG based on industry used, the MPoC SDK implemenis its own DRNG Minimum and Eguivalent Key Sizes and Strengths for 

standards. based on weli-known international and industry- Approved Algorithms. 

standard algorithms suitable for cryptography use. Homegrown algorithms do not provide enough assurance 

on the guality of the random numbers provided or the 
security of the algorithm. It is expected that the algorithms 
used by the MPoC SDK use international and industry- 
standard algorithms (e.g., NIST SP 800-904). 

i 1A-2.4 DRNGs used by the MPoC SDK 1A-2.4.a The tester must confirm through A DRNG is by definition deterministic — given the same 
must be regularly (re)seeded with examination that, for each DRNG used in tbhe MPoC | input, it will produce the same output. Therefore, it is 
unpredictable values of sufficient entropy, | Software: important that the input to a DRNG — the “seed” — is 
which are protected for confidentialityand | , The geeds have appropriate entropy (at least sufficientiy unpredictable. 
integriiy. egual to the strength of any random value they (| To ensure that a compromise of a DRNG state during 

are reguired to produce). operation does not result in the compromise of all further 
w hs seedecii deliveil from ikusisdsoliiGEs values output from that DRNG, the DRNG is reguired to 
TE d : iki ; be regularly reseeded. 
i AN li agalnsi Gi b Random seed values transmitted from external systems 
» The seedsare protected against tampering. may be protected using the secure channel implemented 
»e The MPoC Software implements protections for that connection. 
against tampering of the DRNG and its seeding 
process. 
» The DRNGis seededatleast each time the 
MPoC Software launches, and reseeded after 
every 24 hours of continuous operation. 
» The DRNG seeding process is performed if the 
integrity and confidentiality of ihe DRNG state 
cannot be ensured, such as upon launch or 
return from a halted state. 
»e İnallcases,the DRNG isreseededalter 24 
hours has elapsed since the last seeding 
process. 
Note: This reguirement only applies to systems 
using a DRNG assessed under reguirement 1A-2.3. 
Note: Appendix C outlines the reguiremenis for 
minimum entropy of cryptographic keys. 
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1A-2.5 The DRNG used by the MPoC 1A-2.5.a The tester must confirm through The DRNG used by the MPoC SDK can use different 
SDK must use more than one source of examination that the DRNG seeding process sources of entropy to obtain its seed (e.g., one HSM and 
entropy to obtain its seed. Entropy includes random data from a trusted external ihe COTS platform Random Number Generator (RNG)). 
sources must include at least one external | source, such as a PCI PTS SCRP or back-end This increases the effort needed to compromise the 
trusted source, as well as a source from HSM, in addition to one from the COTS device. DRNG used by the MPoC SDK. 
ihe COTS device. Note: This reguirement only applies to systems The back-end random data can be obtained from the 


using a DRNG assessed under reguirement 1A4-2.3. | back-end HSM. The random data taken from the COTS 
device can be obtained from one of the COTS platform 
Random Number Generator (RNG) sources (OS, TER, 
SE) or from another method of collecting unpredictable 
data. By using these two sets of (re)seed data from 
different systems (COTS device, and external) it provides 
confidence that the eniropy sources used are 
independent. 


Where HSMs are used, the compliance and testing 
reguiremenis for these are covered in the operational 
Domains of this standard, in reguirements 4A-2.x. 
Reguirement 4A-2.2 specifies that HSMS used in the 
back-end systems are reguired to be compliant to 
FIPS140-2 level 3 (or above) or PCI HSM. 


The need for an external entropy source does not apply if 
ihe COTS platform provides a suitable hardware RNG, 
such as through an SE or TEE, which is used by the 
MPoC SDK. Note that this applies only if a hardware RNG 
is provided, not to DRNGs, which are the focus of this 
reguiremenit. 
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1A-2.6 The reseeding method used by 
the MPoC SDK must add enitropy to the 
DRNG state instead of replacing the 
existing entropy. 


Test Reguiremenis 


1A-2.6.a The tester confirms through examination 
that the method to reseed the algorithm is secure 
and the entropy used to reseed does not completely 
determine the future states of the DRNG (i.e., 
entropy is added to the state of the DRNG instead 
of re-instantiating the DRNG). 


1A-2.6.b The tester must confirm through 
examination that the method used to combine the 
collected entropy inputs into a single seed for the 
DRNG maintains the entropy of each seed, such as 
by XORing each seed value into a single entropy 
pool. 


1A-2.6.c The tester must confirm through 
examination that any entropy pool maintained for 
the DRNG implements methods to protect the 
integrity and confidentiality of that pool. 


Note: This reguirement only applies to systems 
using a DRNG assessed under reguirement 1A-2.3. 


Guidance 


When reseeding the DRNG, the new seed is reguired to 
add to the enitropy of the DRNG and not be used to re- 
instantiate the DRNG to a previous or known state. This 
helps to mitigate the risk that a compromised future seed 
can be used to completely determine the output of the 
DRNG. 


Adding to the entropy of the DRNG, rather than 
implanting another seeding process to restart the DRNG, 
ensures that any attacker who has compromised the 
current entropy values is not able to determine the output 
of the DRNG unless they have captured all entropy 
seeding values. This mitigates attacks against externaliy 
supplied entropy, such as that supplied by a PCI PTS 
SCRP or HSM. 


Some implementations may prevent the reseeding of the 
platform Random Number Generator (RNG). In such 
cases, either a separate Random Number Generator 
(RNG) will need to be used or methods other than 
reseeding will be reguired to ensure sufficient entropy for 
the platform Random Number Generator (RNG). 


Reseeding is not reguired for systems that use hardware 
based true Random Number Generator (RNG)s, such as 
secure elemenis or trusted execution environment 
assessed to provide such functions. 
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Cryptography is an important factor to ensure confidentiality and integrity of data and processes that support the MPoC Solution. 
Therefore, it is important that only industry-recognized standard cryptographic algorithms and modes of operation be the basis for any 
security services used in the MPoC Solution. 


Sensitive assets are reguired be encrypted on the COTS device for transporting to other componenis of the MPoC Solution using 
cryptographic algorithms and modes of operation known to provide suitable levels of security. 


All cryptographic keys are reguired to be used for a single specific purpose. For example, a key used to encrypt account data is not 
permitted to also be used to protect the integrity of the tamper-detection data. 


This reguirement does not apply to cryptographic methods applied by the PCI PTS SCRP for onward processing by the payment 
processing environment (e.g., PIN block translation functions performed by the PCI PTS SCRP, which have been previously assessed 


to PCI PTS POJ standard). 


Security Reguiremenits 


Test Reguiremenis 


Objective: Industry-standard and accepted cryptography is used to protect sensitive assets. 


Guidance 


1A-3.1 Software-development 
documentation must provide details about 
acceptable cryptographic processes and 
operations to be used for security 
services. 


1A-3.1.a The tester must confirm through 
examination that the reguired information is present 
and matches the design of the solution. 
Documentation must include, but not be limited to, 
the following: 


The cryptographic algorithms and key sizes that 
must be used for security services. These must 
be compliant with Appendix C Minimum and 
Eguivalent Key Sizes and Strengths for 
Approved Algorithms when used for security- 
sensitive service. 


Key-generation or key-agreement processes. 


Description of cryptographic key protection 
mechanisms. 


Key derivation functions used, including any key 
check value, check values, or other derivation 
functions. 


Modes of operation. 


Information that identifies cryptographic operations used 
in the solution helps ensure that these controls and their 
use are appropriately understood prior to testing. It also 
helps to identify areas where cryptography may increase 
the solution's security protection. 


This software development documentation provides 
guidance and outlines the necessary controls and 
features for the development of the solution. Therefore, 
references to cryptographic algorithms or key lengths 
need to be in line with other testing reguiremenis (e.g., 
minimum acceptable algorithm types and key lengths). 


The remaining reguirements in this Section describe the 
testing reguired to validate that the implementation is 
produced in line with the rules of the software- 
development process. 
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1A-3.2 All cryptographic processes, 
including hash functions, used to provide 
security to the solution must adhere to 
Appendix C Minimum and Eguivalent Key 
Sizes and Strengihs for Approved 
Algorithms. 


Test Reguiremenis 


1A-3.2.a The tester must confirm through 
examination that the cryptographic algoritams and 
the key sizes comply with Appendix C Minimum and 
Eguivalent Key Sizes and Strengths for Approved 
Algorithms. 


Guidance 


To withstand attacks, the solution is reguired to use the 
most robust and current encryption algorithams and key 
sizes. Legacy algorithms may have known weaknesses 
and provide security levels that are unsuitable given 
current and projected computing power. 


Use of recognized cryptographic methods ensures that 
the solution adheres to industry-tested and accepted 
algorithms and appropriate key lengihs that deliver 
effective key strength and proper key-management 
practices. Proprietary or “home-grown” algorithms do not 
provide this assurance and are not permitted. 

Hash functions are used to provide integrity and support 


authenticity controls over data. They may be used on their 
own or in combination with other cryptographic controls. 


1A-3.3 Public keys used by the MPoC 
Software must be protected for integrity 
and authenticity and be authenticated 
before use of the certificate. 


1A-3.3.a The tester must confirm through 
examination and observation that the public keys 
used in the MPoC Software are protected for 
authenticity and integrity. 


1A-3.3.b The tester must confirm through 
examination and observation that the public keys 
used in the MPoC Software are authenticated prior 
to use. 


Certificates are often used to exchange public keys. 
Verification of certificate signatures can be used to 
authenticate the public key and meta data. This is 
normally guaranteed by verifying the complete certificate 
chain up to the certificate authority. 


However, in the case of MPoC Software, some 
certificates may be signed by the MPoC Solution provider 
and not by an established CA. These certificates can be 
authenticated by using application package signature as 
the root of trust protecting the application-embedded 
certificate(s) against tampering. 

For certificates used by the MPoC Software that are 
signed by the MPoC Solution provider, a self-signed 
certificate embedded in the signed MPoC Software 
package may be used to validate other certificates. 
Reguiremenits for the security of signing operations 


performed by the MPoC Solution provider can be found in 
Domain 4 of this standard. 
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1A-3.4 Fach key must have a single 
unigue purpose, and no keys may be 
used for multiple purposes. 


Test Reguiremenis 


1A-3.4.a The tester must confirm through 
examination that the cryptographic keys used in the 
MPoC Software are not used for multiple purposes, 
specifically noting the findings for the PIN and 
(other) account data keys. 


Guidance 


The MPoC Software is reguired to prevent the use of a 
single key for more than one purpose (e.g., signing and 
encrypting data, or using a key encrypting key to encrypt 
PANSs). This helps to reduce the impact of the 
compromise of any one key. 


The disclosure of a secret or private key needs to be 
prevented from compromising data not intended to be 
protected by that key (e.g., so the compromise of a key 
that protects card data cannot expose PIN data). 


Keys used in industry-standard protocols, such as TLS, 
are not included in this reguiremenit. 


A key that exists higher in the hierarchy can be used to 
generate or derive multiple keys, each with its own 
purpose, if the key derivation method used is secure. This 
is assessed in the next reguirement. 


i 1A-3.5 Key derivation and key check 
functions are implemented securely. 


1A-3.5.a The tester must confirm through 
examination that the derivation and key check 
functions present in the MPoC Software are one- 
way functions and do not expose information about 
ihe keys used in the derivation or check process. 


1A-3.5.b The tester must confirm through 
examination that it is not possible to calculate the 
derivation or key check function output without prior 
knowledge of the derivation or key check material, 
including the cryptographic key used. 


Derivation and key check functions need to be selected 
such that an attacker cannot gain information of the key 
used as part of the derivation or check process (the 
“derivation key” or “original key”) by observing the derived 
value, or a set of them. 

Examples of derivation functions that do not reveal the 


derivation key are encryption and one-way functions such 
as CMAC. 
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14-4 Key Management Design 


Secure key management is critical to the security of cryptographic systems. It is a fundamental factor for ensuring the confidentiality and 
integrity of data and processes that support the MPoC Solution. key management practices must conform to the indusiry-accepted 
practices described in this Section. Cryptographic keys are managed securely using recognized industry reguiremenis throughout the 
cryptographic lifecycle including, but not limited to: 


" oGeneration 

" o Distribution/conveyance 

" Storage 

" oEstablished cryptoperiods 

" o Replacementrotation when the cryptoperiod is reached 
" oEscrow/backup 

" oOKey compromise and recovery 

» oEmergency procedures to destroy and replace keys 

" o Accountability and audit 


Secret and private cryptographic keys that are relied upon for security are reguired to be unigue per device/application, with the 
exception of keys protected through software-protected cryptography means, which are used to establish an initial trust anchor prior to 
provisioning unigue keys to the MPoC Application. Shared public keys are acceptable, but methods and procedures for revoking 
compromised public key/private key pairs must be implemented. For additional information about public key Infrastructure (PKI), refer to 
X9.79-4. 


Operations that involve secret or private cryptographic keys are to be performed using split knowledge. Split knowledge reguires that no 
one person can determine any single bit of a secret or private cryptographic key. Split knowledge can be provided in the following ways: 


" oStoring keys on secure cryptographic devices (SCD) approved by FIPS140-2 Level 3 (or eguivalent in FIPS 140-3) or PCI PTS- 
HSM that will not output the cleartext key. 


" İTwoormore fuli-lengih components during key loading. 
« An M-of-N secret-sharing scheme. 
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Test Reguiremenis 


Guidance 


Objective: Cryptographic keys that protect the MPoC Software and the sensitive assets are securely managed. 


i 1A-4.1 An inventory of all keys used by 
the MPoC Software must be 
maintained. 


1A-4.1.a The tester must confirm through 


examination that the information provided matches 


their understanding of the MPoC Solution and 


contains the reguired information for all keys used in 


the MPoC Software. 


For each key, the information must be provided 
containing at a minimum: 


» İDornameofthekey 
» (o Function/purpose 


» (o Ünigueness(eg,., per transaction, device, 
solution, etc.) 


» o Algorithm andkeysize 
» o Criyptoperiod (key lifetime) 


» (Key-generation location (Name of server, 
application, database, device, etc.) 


» (O Key-generation method (SCD, PCI PTS SCRP, 


OS, SE, TEK, software, etc.) 


» Key usagelocation (name of server, 
application, database, device, etc. For 
symmetric keys this is at least 2 locations.) 


» Keyloading (where relevant, how is the key 
loaded?) 


» o Confidentiality protection during transport 
» o Confidentiality protection during storage 
» o İntegrity protection during transport 

» o İntegrity protection during storage 

» Removal/destruction 


A good key-managemeni process, whether manual or 


automated, is based on industry standards and addresses 


all elemenits of the key lifecycle that include: 
» o Distribution/conveyance 

» Storage 

» o Establishedcrypto periods 


» (Replacementrotation when the cryptoperiod is reached 


» Escrow/backup 
» (Key compromise andrecovery 


» (Emergency procedures to desitroy and replace keys 


» (o Accountability and audit 


For example, key generation is reguired to conform to 


industry-recognized procedures that ensure the 


confidentiality of the underiying key. Secret and private 
cryptographic keys need to be distributed securely, never in 
the clear, and only to designated custodians or recipienis. 
Procedures for distribution apply both within the entity and 


outside İt. 


Secret and private keys are reguired to be encrypted with a 
strong key-encrypting key that is stored separately, stored 
within an SCD (such as an HSM), or stored as at least two 
fuli-length key components or key shares in accordance 


with an industry-accepted method. 
(continued on next page) 
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1A-4.1.b The tester must document a separate key 
table that outlines all cryptographic keys used in the 
MPoC Software for the security of the solution. 


Guidance 


A cryptoperiod needs to be identified for each key based on 
a risk assessmeni, and keys are reguired to be changed 
when this period is reached. Additionally, keys are reguired 
to be immediately prevented from use. Compromised keys 
should be desiroyed and replaced promptly upon 
confirmation of a compromise. Secure key-management 
practices include: 


» Minimizing access to keys to the fewest number of 
custodians necessary. 


» (o Enforcing split knowledge and dual control for activities 
involving cleartext keys or key componenis. 


» Definingroles andresponsibilities for Key Custodians 
and Key Managers. 


The key inventory must include any public keys or 
certificates used by the solution. Where possible, 
certificates should be maintained in a standard format such 
as X.509. When certificates are used or stored in other 
formats, information about the certificate use and context 
may need to be stored in another format. 


For example, a specific protocol or implementation may use 
public keys in a format referred to as a certificate, which 
does not necessarily provide an “İssued to” field. When this 
is the case, the data may be intrinsic to the implementation 
or may be stored within the certificate inventory itself. 
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1A-4.2 Secret or private keys must be 
imported to the MPoC Software in a 
form that protecis their confidentiality 
and integrity, and does not solely rely 
on the protections provided by any 
secure channel(s) being used. 


Test Reguiremenis 


1A-4.2.a The tester must confirm through 
examination and observation that secret and private 
keys are imported or injected into the MPoC 
Software only in a way that protecis their 
confidentiality and integrity. 


1A-4.2.b The tester must confirm through 
examination and observation that the confidentiality, 
integrity, and authenticity protections do not solely 
rely on the use of a secure channel. 


1A-4.2.c The tester must confirm through 
examination and observation that keys used to 
encrypt other keys for transport are not also used to 
secure keys during storage. 


Guidance 


Reguirement 4A-2.6 covers the operational aspecis of key 
management, and notes that key blocks are one way of 
protecting the confidentiality and integrity of cryptographic 
keys. 


When the MPoC Software reguires secret or private 
cryptographic keys to be imported, these need to be 
protected. 


It is not sufficient to send such keys protected only using 
secure channel protection, such as TLS. The keys are 
reguired to have their confidentiality separately protected, 
such as through use of a key encryption key dedicated for 
that purpose. 


Keys should be created, and securely maintained, within the 
environment where they are used (e.g., hardware-backed 
keystore, software-protected cryptography, secure elemeni, 
etc.). Alternatively, cryptographic keys may be securely 
imported in an encrypted form, such that keys are not 
exposed outside of the environment where they were 
generated. 


Use of the same cryptographic keys for transport and 
storage can cause additional risk of exposure to the 
operational keys being transported or stored. 


Entering secret or private cryptographic keys as cleartext 
exposes the value of that key. Implementations need to 
ensure that the eniry of secret or private cryptographic keys 
does not reduce the security of those keys. 


Implementations may export a secret or private key from an 
SCD directly into the MPoC Software, so that no one “sees” 
the key value, as long as the key is sufficientiy protected 
after export (e.g., through the use of white-box cryptography 
for keys stored in the MPoC SDK, or storage in a hardware 
key store or HSM). Alternatively, an implementation may 
import working keys encrypted under another (transport) 
key. 

Alternatively, keys may be input using processes for “dual 
control and split knowledge,” which provide for the eniry of 
key componenis using multiple key custodians. 
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Test Reguiremenis 


Guidance 


This reguirement covers only the support for secure key 
importing. Operational aspects are considered under the 
operational reguiremenits of this standard. 


1A-4.3 Secret or private keys 
embedded into an MPoC SDK must 
implement software protection methods 
and not be exposed in cleartext. 


1A-4.3.a The tester must confirm through 
examination and observation that if secret and 
private keys are embedded in the MPoC SDK, they 
are in a form that is protected with software-based 
protection measures such as software-protected 
cryptography. 


1A-4.3.b The tester must confirm through 
examination that any software protection measures 
used are compliant to the 1B-2.x reguiremenits of 
this standard. 


1A-4.3.c The tester must confirm through 
examination that secret or private cryptographic 
keys are not embedded in any other aspecis of the 
MPoC Software, other than the MPoC SDK. 


When secret or private keys are embedded in the MPoC 
Software, they need to be protected using software methods 
such as software-protected cryptography. 


Embedding of secret or private cryptographic keys in 
aspecis of the MPoC Software other than the MPoC SDK is 
not permitted. 


1A-4.4 Certificates that exist on the 
COTS device as part of the COTS OS 
must be considered in scope if used by 
the solution for security purposes. 


1A-4.4.a The tester must confirm through 
examination that any certificates used by the MPoC 
Solution, which are part of the COTS OS, are 
included into the scope of the assessmenit. 


Certificates that exist on the COTS device as part of the 
COTS OS may be considered out of scope if the solution is 
not using these certificates. Where certificates or public 
keys are used, they are reguired to meet the relevant 
reguiremenis for key strength and protection. 
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Security Reguiremenis 


1A-4.5 Cryptographic keys must be 
established using a process that 
ensures the entropy and confidentiality 
of the key. 


Test Reguiremenis 


1A-4.5.a The tester must confirm through 
examination and observation that all cryptographic 
keys established by the MPoC Software use 
processes that ensure the eniropy input to each key 
is at least egual to the effective strength of that key. 


1A-4.5.b The tester must confirm through 
examination, observation, and interview (where 
appropriate) that all cryptographic key generation 
processes are designed and implemented in a way 
that protects the confidentiality of the cryptographic 
keys. 


Guidance 


Cryptographic keys need to be established using processes 
that ensure their strength and confidentiality. This may 
include use of an approved DRNG, remote key injection, or 
a secure key agreemeni protocol. Output of cleartext secret 
or private cryptographic keys exposes those keys to 
potential compromise. 


For reguiremenis outlining the effective strength of 
cryptographic keys, refer to Appendix C. 


1A-4.6 The MPoC Software must 
support the use of HSMSs for storage 
and operation of secret and private 
cryptographic keys in the back-end 
environmenis. 


1A-4.6.a The tester must confirm through 
examination and observation that the MPoC 
Software is created to support the use of HSMs for 
storage and operation of cryptographic keys in the 
back-end environmenis. 


Operational key management conirols in Domain 4 reguire 
the use of HSMS to secure cryptographic keys used in the 
MPocC Solution. To ensure that any separately listed MPoC 
Software product does not prevent compliance to later 
operational reguiremenis, it is important that the software is 
created to support HSM use. 


1A-4.7 The MPoC Software must 
implement methods to revoke or 
otherwise cease the use of 
compromised cryptographic keys or 
certificates. 


1A-4.7.a The tester must confirm through 
examination and observation that the MPoC 
Software is able to revoke or otherwise cease the 
use of cryptographic keys or certificates that are 
suspected of being compromised. 


The secrecy and security of cryptographic keys, including 
the private keys associated with public key certificates, is 
the primary protection provided by cryptographic systems. If 
a key or certificate is suspected of being compromised, it is 
iherefore vital to ensure further use of that key is prevented. 
Protections of this type can be implemented through 


methods such as certificate revocation lists (ORLs) or 
through explicit replacement of suspected keys / certificates. 


1A-4.8 Cryptographic keys must not be 
protected with a key of lesser strength. 


1A-4.8.a The tester must confirm through 
examination and observation that the MPoC 
Software does not allow for a cryptographic key to 
be protected by a key of lesser strength. 


It is common for cryptographic keys to be protected in some 
way by another cryptographic key — either through 
encryption (to provide confidentiality protections) or a digital 
signature or (H)MAC (to provide authenticity protections). If 
the key providing protections is weaker than the key it is 
protecting, this can become the most easily exploited path 
to the compromise of that key. 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0 
© 2022 PCI Security Standards Council, LLC. All rights reserved. 


November 2022 
Page 64 


» Security Li 
Standards Council 


14-5 Secure Channels 


A secure channel is a communications connection that protects the data and assets communicated across it. Secure channels can be 
provided by physical means using tamper-responsive hardware or by logical means using transmission security protocols such as TLS, 
or application layer cryptographic methods. Secure channels are vital to protect all communications between the various MPoC 
componenis including (where present): 

" Between the MPoC SDK and external card reader(s) 

" Between the MPoC SDK and back-end environmenis 


If internal systems such asa TEE or SE are used, and these provide for the use of a secure channel to protect communications 
between itself and the RERE, then these protections must be used. 


Security Reguiremenits | Test Reguiremenis | Guidance 


Objective: Connections between separate elemenis of the MPoC Solution are protected and authenticated. 


1A-5.1 Secure channels established by 1A-5.1.a The tester must confirm through A secure design of the communication channels assists 

tihe MPoC Software must be documented. | examination that the vendor secure channel with protecting assets during transit. For a resilient 
information matches the design of the solution. The | design, it is necessary to have a clear understanding of 
information must include at a minimum: how the secure channel is established and the root of 


trust relied upon for that secure channel. 


» The endpoints of each secure channel. 

*  Theroot of trust used for each secure channel. | An MPoC SDK will often establish more ihan one secure 
channel for its operation. It is not necessary that a single 

*  Cryptography supported by each secure root of trust İs used for all secure channels established. 


channel. A , : 
Mutual authentication is not reguired upon first execution 

» o How the channel is established and how mutual | ofthe MPoC SDK, as it is expected that no instance 

authentication İs guaranteed. unigue cryptographic keys will have been provisioned at 
this stage. However, mutual authentication is reguired for 
secure channels once the initial 
provisioning/personalization process has completed, and 
prior to the performance of any paymeni transactions. 
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Security Reguiremenis 


1A-5.2 Connections between different 
physical and logical elements of the 
solution must be secured. 


Test Reguiremenis 


1A-5.2.a The tester must confirm through 
examination that communication channels between 
different physical and logical elements are protected 
using secure channels where possible. The tester 
must document how the secure channel is 
established, how the root of trust is defined and 
implemented, and if the secure channel is sufficient 
to protect the confidentiality and authenticity of the 
connection. When security methods rely on 
properties of the COTS platform instead of a secure 
channel, the tester must document these methods 
and confirm that they are suitable for use and that 
ihey are present on the platforms being used. 


Guidance 


When elements are physically separate, a secure channel 
is reguired to protect the communications between these 
elemenits. Such secure channels need to ensure data 
confidentiality and authenticity during the establishment 
and subsegueni use of the channel. No secret or 
sensitive assets are permitted to be transferred prior to 
ihe establishment of the secure channel, excepi for any 
data specifically used for the secure establishment of that 
channel. 


In addition, it is important that all solution componenits, 
including different software modules that exist on the 
same COTS device or server such as attestation 
component and contactless kernel components, establish 
secure connections such that the communication cannot 
be tampered with or accessed without proper 
authorization. These secure connections may be 
implemented through cryptographic means using a 
secure channel as defined in these reguiremenis, or using 
properties provided by the COTS platform or server 
platform for protecting the communications. 


Put another way, although it is a reguiremeni that 
communications between different logical and physical 
componenis are secured, it is not always the case that a 
logical secure channel — such as a TLS connection — is 
implemented. 


1A-5.3 Secret or private cryptographic 
keys used to establish and maintain 
secure channels between the elemenis of 
tihe MPoC Software must be unigue per 
session excepi by chance. 


1A-5.3.a The tester must confirm through 
examination and observation that the keys used for 
the secure channels are unigue per session except 
by chance. 


Logical secure channels rely on cryptographic 
protections. Ensuring unigue keys per session helps to 
isolate each connection, prevent replay or relay attacks, 
and complicate potential compromises of the 
cryptographic controls. 


1A-5.4 Logical secure channels must 
implement strong cryptographic controls 
for confidentiality, integrity, and 
authenticity. 


1A-5.4.a The tester must confirm through 
examination that any logical secure channels 
implement cryptography compliant with Appendix C 
of this standard. 


Mutual authentication between the communicating 
componenis is reguired to be based on cryptography that 
aligns with Appendix C: Minimum and Eguivalent Key 
Sizes and Sirengths for Approved Algorithms. 
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Security Reguiremenis 


1A-5.5 Fach secure channel that extends 
outside of a physically protected boundary 
must provide mutual authentication to 
uniguely identify each component prior to 
the exchange of sensitive assets and 
protect against MITM and replay attacks. 


Test Reguiremenis 


1A-5.5.a The tester must confirm through 
examination and observation that the secure 
channels that extend outside of a physicaliy 
protected boundary perform mutual authentication 
before any exchange of any assets. 


Guidance 


During the installation of the MPoC SDK or integrating 
MPoC Application, it is normally not possible to 
authenticate the merchant COTS device as all the 
installable packages are the same for the same COTS 
device model. Currently, however, there are no unigue 
assets provisioned to the MPoC Software and it cannot 
perform transactions. 


It is expected that after initial download, the MPoC SDK 
receives the necessary data to enable its authentication 
by the backend in future interactions. It is not acceptable 
for ihe MPoC SDK to “re-provision” each time it is 
reguired to re-establish a secure channel, mutual 
authentication is reguired to be implemented for all 
connections after the initial provisioning process. 


Certificate pinning may be used in part to meet this 
reguirement and is implemented by limiting the allowed 
certificates that can be used as aroot of trust. For 
example, embedding a certificate in the MPoC SDK to 
verify the back-end certificate instead of using the 
platform certificate store for this purpose is one method of 
certificate pinning. 

Cryptographic mutual authentication is not reguired for 
communication connections entirely within the physical 
boundary of the COTS device, or within the physicaliy 
secure areas of the back-end processing systems. 


1A-5.6 The secure channel must prevent 
downgrade attacks. 


1A-5.6.a The tester must confirm through 
examination, observation, and testing that the 
secure channels are not susceptible to downgrade 
attacks. 


A downgrade attack may result in switching to a previous 
version of a protocol or a lower security setting of the 
same protocol, such as reducing the level of encryption 
applied. 


The solution needs to prevent the downgrade of any 
protection levels provided by the secure channels. 
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Security Reguiremenis Test Reguiremenis Guidance 
1A-5.7 Assets must be encrypted and 1A-5.7.a The tester must confirm through The MPoC Software assets need to be protected for 
authenticated at the datagram level during | examination and observation that assets in transit confidentiality and authenticity when transmitted through 
transport, and not solely rely on the are protected using application-level encryption a secure channel. 
protections provided by any secure applied at the data level in addition to the security It may be possible to strip the protocol used by the secure 
channel being used. and encryption provided by the secure channel. channel, such as TLS, or intercept the data as it passes 


to libraries that implement the protocols used. 


Therefore, encryption at the application level is needed to 
provide an additional layer of security that cannot be 
stripped easily. 

Assets only include the sub-set of assets that reguire 
confidentiality protection, and the MPoC Software is not 
reguired to be protected in this way. 
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14-6 Third-Party APis 


Al MPoC Software will expose APls to allow for integration of the MPoC Software into the overall MPoC Solution. Some MPoC 
Solutions may also provide other API interfaces to other applications or systems (e.g., where the MPoC SDK performs payment 


functions only and receives the amount from other applications in a reguest for payment processing). In all cases, it is important that the 


APls provided are documented clearly and implemented securely so as not to compromise the security of the paymeni process. 


Security Reguiremenits 


Test Reguiremenits 


Objective: Assets that are transmitted through APls to third-party applications are protected. 


| Guidance 


i 1A-6.1 Documentation of any API 
exposed to third parties must exist. 


1A-6.1.a The tester must confirm through 
examination that information provided includes the 
following at a minimum: 


» Ul display datathatis communicated through 
third-party APls exposed by the MPoC 
Software. 


» (o Guidancefor users of the API abouthowto 
securely use the API and protect the Ul display 
data on the external application. 


As part of the security design of the MPoC Software, the 
Ul display data that is communicated to external parties, 
including the exposed API, need to be identified. As the 
handling of these Ul display data involves an external 
third-party application, information needs to be included 
that guides the external application to take appropriate 
measures to proteci the assets. 


This reguirement does not mandate that Ul display 
functions are provided to the MPoC Application or other 
calling applications. 


1A-6.2 APls exposed by the MPoC 
Software must not introduce 
vulnerabilities to the MPoC Solution and 
must provide only the defined 
functionality. 


1A-6.2.a The tester must confirm through 
examination that any APls exposed by the MPoC 
Software cannot reduce the security of the overall 
MPocC Solution. 


The MPoC Software may expose APls to provide for 
integration with other systems. Such APls are not to 
reduce the security of the overall MPoC Solution when 
used. 


The data transmitted through exposed APls needs to be 


1A-6.2.b The tester must confirm through 
examination that any APls implemented expose 
only the defined functionality to provide the intended 
features. 


limited to the minimum reguired and never contain 
cleartext account data. 
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Security Reguiremenis Test Reguiremenis Guidance 

1A-6.3 APls exposed by the MPoC 1A-6.3.a The tester must confirm through Refer to table 4 in the introductory parts of this standard 

Software must secure assets accordingto | examination that the protection type of the for examples of MPoC assets. 

their reguired protection type. communicated assets is maintained in any API If assets, such as transaction data or A&M data, are to be 
interface. communicated through an API, these assets are reguired 

to maintain the protection type that is reguired in the 

1A-6.3.b The tester must confirm through overall MPoC Solution. For example, if an identifier 
examination that, excluding non-sensitive payment reguires confidentiality protection, it is reguired to be 
initiation data such as the amount, any assets communicated with its confidentiality protected and not in 
included in any APls are protected according to their | cleartext. 
protection type. 


Protection may be provided using cryptographic means if 
ihe assets is to be exposed in untrusted memory or 
processing spaces, or through the shared memory 
protections provided by an integrated MPoC Software. 


This reguirement should be considered in conjunction 
with reguirement 1D-1.2, which covers the encryption of 
account data. 


Non-sensitive payment initiation data, such as a payment 
amount, İs an exception to this reguirement. Assets that 
are already sufficientiy protected through encryption by 
the MPoC Software are also out of scope of this 
reguiremenit. 
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Module 1B: MPoC SDK Software Protection 


These reguirements apply to the MPoC SDK, or the aspecis of the MPoC Application that provide security and paymeni features (in the case 
of monolithic MPoC Applications). The reguiremenis of this Module 1B do not apply to the back-end aspecis of the MPoC Software. 


1B-1 Software Security Mechanisms 


The security mechanisms that protect the MPoC SDK from attacks, such as reverse engineering, modification, and monitoring, also help 
protect the MPoC Solution assets as they are entered into, processed by, and transferred from the COTS device. The security 
mechanisms not only have a preventive role in the MPoC Software's security; they also work as detection mechanisms where they are 


tied to the A&M. 


Many types of security mechanisms exist, each with different strengths and protection goals. It is important that the security design of 
the MPoC Software considers the coverage of the security mechanisms and the interaction between them. Furthermore, it is important 
that the level of protection (strength) of the security mechanisms is evaluated. 


Security Reguiremenits 


| Test Reguiremenits 


| Guidance 


Objective: The MPoC SDK implements security mechanisms that protect assets and resist tampering attempis. 


i 1B-1.1 The security mechanisms 
implemented in the MPoC SDK must be 
documented. 


1B-1.1.a The tester must confirm through 
examination that the information provided is 
complete and consistent with the tester's 
understanding of the solution. This information must 
include the list of security mechanisms included in 
the MPoC SDK, with the following items for each 
mechanism at a minimum: 


» Whatthemechanism protecis against. 


» The party responsible for providing and/or 
implementing the security mechanism (i.e., the 
MPoC SDK or the platform). 


» Thelocation or component where the 
mechanism is implemented (e.g., REE, TER, 
SE). 

» The original source and provider of the 
mechanism (e.g., third-party vendor, MPoC 
Software vendor). 


The MPoC SDK is reguired to implement protections to 
mitigate attacks on the MPoC SDK and assets, both 
during execution and when the MPoC Software is 
installed but not currentiy being executed. Multiple 
individual protection methods are likely to be reguired; 
therefore, it is important that each of these is documented 
and provided with details about how it works and what it is 
designed to protect. 


Where the MPoC SDK relies on previous evaluation or 
approval of subsystems, such as through use of an 
approved MPoC Software product, or an evaluated 
secure element/irusted execution environment, then the 
MPoC Software vendor can reference this high-level 
approval rather than outline each individual security 
feature provided by that subsystem. 


Details indicating what security mechanisms the MPoC 
SDK implement are important so that the integrating 
MPoC Application can ensure these security features are 
properly integrated and used. 
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Security Reguiremenis 


1B-1.2 All assets managed by the MPoC 
Software must be identified. 


Test Reguiremenis 


1B-1.2.a The tester must confirm through 
examination that the assets are correctly identified 
according to the testers understanding of the MPoC 
Software. The information provided must include, 
but not be limited to, the following: 


Assets name and description. 


Components that have access to the assets in 
cleartext (or have enough information to recover 
it in cleartext (e.g., encrypted assets and 
encryption key). 


How the assets are protected according to their 
reguired protection type (e.g., confidentiality, 
integrity, authenticity) and lifecycle stages 
(generation, transmission, storage, process, 
and removal). 


Code flows involving assets. 


1B-1.2.b The tester must confirm through 
examination that the identified assets protections 
are appropriate for the type of assets. 


Guidance 


Assets in the context of this reguirement are resources or 
information valuable to the stakeholder or operation of the 
MPoC Solution, that need protection. Examples of assets 
include cryptographic keys, account data, information 
supplied or used as part of an attestation system, etc. 
Refer to Table 4 for examples of MPoC assets. 


The tester needs to use their understanding of the 
operation and security implementation of the MPoC 
Software to identify the assets managed by this software 
during operation. 

The identification of assets and a strategy to protect them 
during the lifecycle is crucial for a secure design of the 
solution. 
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Security Reguiremenis Test Reguiremenis Guidance 
1B-1.3 Platform based security 1B-1.3.a The tester must confirm through If the security mechanisms used by the MPoC SDK 
mechanisms relied upon by the MPoC examination that where security mechanisms used depend on an underlying system such asa TERE, SE, etc., 
SDK to protect the assets must be by the MPoC SDK rely on previous approvals or there needs to be assurance on the security of the 
evaluated. certifications that the evidence and scope of prior underlying system. Any prior certifications relied upon are 
evaluation/certification is sufficient to ensure reguired to be relevant to the payment acceptance and 
security to the assets they protect. security scope of an MPoC Solution. 


Examples of certifications that may be acceptable, 
include, but are not limited to: 


» Common Criteria (at EAL4 with AVA VAN 5) 
1B-1.3.b When prior evaluation is unable to be e o Common Criteria with Global Platform TEE PP 
relied upon, the tester must confirm through » o EMVCoChipandGlobal Platform 
examination, observation, and testing, that security 

mechanisms used by the MPoC SDK provide the # EM SEMEOr Mei 
expected and reguired security properties. e» O PCI-PTSPOJ, PCI HSM 


» FPS 140-2/FIPS 140-3 (Level 34) 


The tester needs to ensure that the scope and methods 
used in the prior evaluation are valid for the current use 
case. If insufficient coverage or testing has been 
performed, re-evaluation of the underiying system, in part 
or whole, may be reguired by the MPoC laboratory. 


This reguirement does not prevent the use of security 
mechanisms that do not have prior evaluation, but where 
any prior evaluation does not exist then further 
assessmeni to confirm the security features provided is 
expected. 


1B-1.4 Storage locations used by the 1B-1.4.a The tester must confirm through When assets (that are reguired to be protected for 
MPoC SDK, including temporary buffers examination about how exposure of cleartext assets | confidentiality) are to be present in cleartext in memory, 
and caches, containing cleartext sensitive | is minimized and how it is ensured that such assets | the time they are present needs to be reduced as much 
assets must be cleared immediately after | are cleared from storage locations immediately after | as possible. This reduces the time that the data is 


use. The time where a sensitive assets is | use. The removal method must not rely on exposed as cleartext and assists in ensuring that memory 
available as cleartext in memory mustbe | language/platform mechanisms (e.g., garbage dumps or reuse do not expose previously processed 
limited to the shortest period of time collectors). values. 

possible. Note: This reguirement applies to whenever 


sensitive asseis are no longer reguired, including 
after early termination of a transaction due to A&M 
or operational conirols. 
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Security Reguiremenis 


1B-1.5 The MPoC SDK must be resistant 
to reverse engineering and cover all 
security-sensitive areas and sensitive 
assets. 


Test Reguiremenis 


1B-1.5.a The tester must confirm through 
examination, observation, and testing that the 
methods used to provide resistance to reverse 
engineering sufficientiy cover the reguired 
functionality, including the following functionality at a 
minimum when present: 


» The contactless kernel code. 


» oCodehandling/interfacing with cryptography 
functionality. 


» Codethathandles the sensitive assets. 
» (o Security mechanisms and A&M code. 


1B-1.5.b Where obfuscation is used as a security 
feature, the tester must confirm through examination 
and observation that the transformations applied by 
the obfuscator include the ability to: 


» Hidedata, such as (but not necessarily limited 
to), function/method names, strings and other 
data, and asset. 


» Modifythe codeflowofthe MPoC SDK. 


Guidance 


Obfuscation may not be reguired if the MPoC SDK is 
executed in a physically separate execution environmeni, 
such asan SE or TEE, which provides physical security 
conitrols that mitigate access to the MPoC SDK code. 


Obfuscation reduces the efficacy of common code 
decompilation tools. Obfuscation methods may include, 
but are not limited to, control-flow and data obfuscation, 
execution of code sections in remote/cloud environmenis, 
and symbol renaming, or protections provided by 
virtualized execution environmenis that are specifically 
designed to provide software-based protections to code 
execution flows (such as a vTEE). 


If the MPoC SDK is provided as a number of files 
(libraries), the calls and interfaces between the libraries 
are reguired to be obfuscated as well. 


Obfuscation is intended to complicate the reverse 
engineering of the software and execution process of the 
MPoC SDK. 


These protections are not reguired across all code, but 
need to be implemented to protect all code that handles 
assets or performs security checks. These protections 
should increase code complexity and increase the 
reverse-engineering effort needed to understand the 
MPoC SDK code. 


Code-shrinking tools, on their own, do not provide 
sufficient reverse-engineering protection. 


1B-1.6 Code and data provisioned to the 
MPoC SDK after installation must be 
transmitted, managed, and stored 
securely. 


1B-1.6.a The tester must confirm through 
examination, observation, and testing that code and 
data provisioned to the MPoC SDK after installation 
is transmitted, managed, and stored securely. 


Note: This reguirement applies to data that is 
security sensitive (e.g., configuration files, 
webviews, keys, etc. as well as to all code that is 
executed by tihe MPoC SDK (that is not already part 
of the COTS Platform), and merchant identifiers 
used as part of the transaction process. 


After installation, the MPoC SDK needs to be provided 
with unigue (configuration) data to be differentiated from 
other installations. During provisioning/personalization 
assets such as key material, configuration, and unigue 
identifiers may be provisioned to the COTS device. Data 
provisioned this way is not covered by the authenticity 
conirols of the OS store and so protections need to be 
provided by the MPoC Solution itsel. 

This includes any merchant identifiers reguired for the 
processing of paymenis, the management of which are 
assessed under the reguiremenis of Domain 5. 
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Security Reguiremenis 


1B-1.7 The MPoC SDK must implement 
methods to detect compromised 
platforms, and maintain the security of 
assets if such platforms are detected. 


Test Reguiremenis 


1B-1.7.a The tester must confirm through 
examination and observation that the MPoC SDK 
implements industry best practice with regard to the 
detection of compromised platforms and protection 
of MPoC SDK assets. This must include detection of 
rooting, as well as other methods that may be used 
to compromise the integrity and security of the 
execution environmeni, including the use of 
emulator systems. 


Guidance 


Some MPoC platforms provide attestation functions that 
can be used by applications to assess the platform 
integrity. 

These mechanisms may be stronger than the ones 
provided by the MPoC SDK because they have insights 
into the platform. However, it may be possible to bypass 
them under certain circumstances. 


Understanding the limitation of these mechanisms and 
their proper implementation is essential for robust 
software hardening. 


Emulators facilitate the dynamic analysis of applications. 
The MPoC SDK is reguired to implemenit protections to 
help prevent its execution on these platforms to prevent 
such analysis. The focus of testing for this aspect of the 
reguirement is not to consider all possible virtualization or 
hardware abstraction layers as non-compliant, but how 
the execution of the MPoC Software on any such system 
may facilitate dynamic analysis, and what protections the 
software implemenis to mitigate such attacks. 


Protections may be applied outside of the MPoC Software 
itself, e.g., through the utility of the execution 
environment. However, any security protection measures 
relied upon are to be considered and confirmed through 
evaluation in this Section. It is not sufficient to reference 
execution within a protected environment and provide no 
further testing or validation of the security of the 
implementation. 
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1B-1.8 After initial download and 
execution, the MPoC SDK installation 
must be securely bound to the COTS 
device on which it is installed. 


Test Reguiremenis 


1B-1.8.a The tester must confirm through 
examination and observation that the MPoC SDK 
implements methods to bind itself to the COTS 
device upon initial execution. It must not be possible 
for the bound MPoC SDK to operate on a different 
device or emulator platform, even if: 


» Dataf(e.g,, files) can be shared from the original 
COTS device to the cloned device. 


» The second deviceis under attacker control. 


Guidance 


After the MPoC SDK is installed, it goes through a 
process upon first execution to uniguely bind that MPoC 
SDK to the specific COTS device on which it is stored. 


The unigue (configuration) data may also hold assets 
related to the merchant account or other operational data. 


The MPoC SDK is reguired to implement controls to 
prevenit the extraction of data from the MPoC SDK such 
that it is not possible to create a “clone” of the MPoC SDK 
that is indistinguishable from the original. 


Additionally, protections binding the MPoC SDK to the 
COTS platform help to mitigate “code lifting” attacks. In 
such attacks, the MPoC SDK (or some portion thereof) is 
“lifted” from the COTS device so that it can be executed 
on another platform, or in an emulated environment, that 
is under the control of the attacker. 


Hardware-backed keystores are often used as part of the 
COTS device-binding solution, as these can be 
implemented so that it is difficult to extract the stored keys 
to clone the MPoC SDK. 

This reguirement is concerned with the technical aspects 
of how the MPoC SDK code is bound to the COTS 
platform, not with the method used to bind a specific 
merchant identity to the MPoC SDK or MPoC Application. 


1B-1.9 The MPoC SDK must be 
developed such that the removal of the 
MPoC SDK or MPoC Application 
integrating the MPoC SDK results in the 
deletion of all associated data from the 
COTS device. 


1B-1.9.a The tester must confirm through 
examination and observation that removal of the 
MPoC SDK, or MPoC Application integrating the 
MPoC SDK, results in the deletion of all associated 
data from the COTS device. 


Provisioned and unigue (configuration) data is not 
permitted to remain on the COTS device after the MPoC 
SDK (or integrating MPoC Application) has been 
removed. Although applications often do not have any 
control over their deletion, consideration during the design 
of the application can ensure that data is handled in a 
way that it is removed from the COTS device when the 
application is removed. 


Where deletion by the COTS OS cannot be relied upon, 
the use of cryptographic deletion may be used. 
Cryptographic deletion refers to when data is encrypted 
with strong cryptography, and the decryption key is 
deleted. In such cases, even when the data remains, it 
may be considered removed for the purposes of this 
reguiremenit. 
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1B-1.10 The MPoC SDK must not contain | 1B-1.10.a The tester must confirm through Prior to the release of a software build, it is common for 
or expose functionality that may examination and observation that there is no option applications to include debug or developer features that 
compromise the security of the MPoC to turn on developer or debugger mode. expose data and functions that would be an unacceptable 
Solution, such as a developer or debug risk in production systems. Such code or features are 
mode. 1B-1.10.b The tester must confirm through reguired to be removed from the distributed software 


examination and testing whether developer mode or GERE Bl psi Gisele Por 18 İŞLE İŞLİ 

debugging code is present or whether it was However, this reguirement does not imply or enforce the 
removed from the installable package. need for two code streams (a test stream, anda 
production stream). Removal of test or debug code during 
a build process may be an acceptable way to meet this 
reguirement. Telemetry and data collection features may 
remain inan MPoC SDK for the purposes of collecting 
A&M data or validating the ongoing correciness of the 
solution. However, any remaining software features are 
not permitted to bypass or disable the security of the 
MPoC Solution or the protections it provides to the 
paymeni assets it processes. 

For example, functions to disable encryption of account 
data or customer PINS, or to use “test” cryptographic 
keys, are not permitted. 


This reguirement includes any MPoC SDK code 
implemented outside the REE of the COTS device. 
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1B-1.11 When any part of the MPoC SDK 
functionality is implemented outside the 
REE, that code must also be protected 
against tampering and must handle input 
data securely. 


Test Reguiremenis 


1B-1.11.a Through examination of the MPoC SDK 
implemented outside the RERE, the tester must 
confirm that the exposed interface between this 
code and the REE is the minimum reguired to 
perform its task. 


1B-1.11.b The tester must confirm through 
examination or testing that any parts of the MPoC 
SDK implemented outside the REE are free from 
exploitable vulnerabilities in their implementation, 
such as memory corruption bugs, type confusion 
bugs, state management bugs, etc. 


1B-1.11.c The tester must confirm through 
examination and observation that cryptographic 
operations and protocols implemented outside the 
REE are implemented and used properly and meet 
the reguiremenis of this standard. 


1B-1.11.d The tester must confirm through 
examination that any parts of the MPoC SDK 
implemented outside the REE are authenticated 
prior to execution. 


Guidance 


The MPoC SDK may implement functionality external to 
tihe REE of the COTS device using TEEs, SES, or other 
separate execution environmenis such as external 
devices or servers. 


It is reguired that this non-REE code is protected against 
tampering, either to interfere with its intended execution 
process or to subveri or intercepi interfaces between this 
code and the RERE. 


Compliance to this reguirement may be achieved through 
demonstration of previous evaluations, such as through 
EMVCo SBMP, GP, or similar scehemes. Documentation 
needs to clearly include authenticatable evidence of such 
evaluation (i.e., a vendor assertion of evaluation or 
compliance is insufficient). 


The tester is expected to validate the scope of any 
previous testing to ensure that any gaps between the 
previous testing and the current implementation are noted 
and accommodated for in the testing. For example, many 
SE or TEE evaluations cover only the hardware and/or 
operating system aspecis of those systems and may not 
include the applications or trustlets used in the MPoC 
Software. 


1B-1.12 The MPoC SDK assets and code 
stored on the COTS device must be 
protected to an attack rating of 25 points 
using the attack-costing framework in 
Appendix B. 


1B-1.12.a The tester must confirm through 
examination, observation, and testing the anti- 
tampering protections for MPoC SDK assets by 
attempting to expose or modify sensitive MPoC 
SDK data stored or processed on the COTS device 
without detection. The tester must provide a costing 
of this attack based on the method outlined in 
Appendix B. Attack Costing Framework. This 
reguiremeni is passed if the most feasible attack 
cannot be costed for less than 25 points. 


Note: It is not intended that the tester attempis to 
extraci all the security assets of the MPoC SDK, but 
only those assets that represeni the least amount of 
effort for an expert attacker, or the biggest gain 
(e.g., PIN). 


The MPoC SDK may store data on the COTS device. 
This data could be abused to change the behavior of the 
MPoC SDK in unintended ways (e.g., change MPoC SDK 
configuration parameters). 


Protection of assets in the solution are reguired to be 
sufficient to withstand expert attackers with local access 
to the COTS device (e.g., a malicious merchant or MPoC 
terminal operator with physical access to the COTS 
device used to accept payments). 


An attack example is an expert COTS device user that is 
able to reverse the MPoC SDK, roots the COTS device, 
and attempis to retrieve cleartext account data. Possible 
conitrols that can be implemented to mitigate the attack 
are COTS OS-level attestation, application integrity 
checks, etc. The combination of controls is reguired to be 
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1B-1.12.b The tester must confirm through sufficient to withstand the attacks and provide the A&M 
examination, observation, and testing the anti- the opportunity to deteci the attack. 
tampering protections for the MPoC SDK code by The goal of this reguiremeni is that the tester provides 


attempting to modify the MPoC SDK code stored on | assurance over the protections that are documented, and 


the COTS device without detection. The testermust | #he security mechanisms interaction and practicalities of 
provide a costing of this attack based on the method possible attacks are understood. 


outlined in Appendix B. Attack Costing Framework . 
This reguiremeni is passed if the most feasible 
attack cannot be costed for less than 25 points. 


Tests performed for this reguiremenit are reguired to be 
executed with the monitoring system disabled to test the 
COTS device security mechanisms in isolation. This 
simulates the temporary disconnection from the A&M 
backend. 


Code protection mechanisms, such as obfuscation and/or 
platform-based protections, do not need to be disabled or 
specifically bypassed prior to this testing. If platform 
security mechanisms such as OS-backed attestation are 
present in the solution, the tester is reguired to consider 
the case where these OS-security mechanisms are 
disabled to assess the non-platform attestation functions. 


Examination only may be sufficient in cases where the 
assets are managed by a component or system that has 
undergone previous evaluation to a known standard, such 
as a HSM compliant to the PCI HSM reguiremenits. 
However, in all cases, it is expected that the tester will 
perform sufficient testing to validate the security of the 
overall MPoC Solution. 
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1B-2 Software-Protected Cryptography 


Protection of cryptographic operations and assets has been traditionally provided by tamper-responsive hardware devices such as 
HSMSs or tamper-resistant hardware devices such as a secure element. Although use of tamper-resistant hardware componenis İs 
becoming more common in COTS devices, support for them is not universal. 


Another way to protect cryptographic operations and sensitive assets is through software protections, such as software-protected 
cryptography, where the cryptographic functions and storage methods used to proteci the cryptographic keys are obfuscated such that 
extraction of the sensitive assets or tracing of the execution flow of the cryptographic process is rendered computationally expensive. 
This includes systems such as white-box cryptography, and implementations where cryptographic operations are executedina 
software-protected execution environment, such asa vTERE. 


When purely software methods are used to protect cryptographic keys, such as with software-protected cryptography, the specific 
instance used in the MPoC SDK is to be changed periodically, where the maximum period is less than the estimated time it would take 
to reverse engineer the software protections. It is acceptable to have two sets of keys during the changeover period, but all old keys are 
to be invalidated when the new keys are installed. The idea behind the update is that the software-protected cryptography 
implementation is updated before the needed time to break it is reached. 


Using protection mechanisms that are inherent to the platform on which the MPoC SDK runs, such as hardware-backed keystore, are 
another option for protecting cryptographic key storage on the COTS device. Combined approaches that use different protection 
methods for different platforms, depending on the security features provided by that platform, or hybrid implementations that use 
combinations of hardware-based and software-based protections may also be acceptable. 


There are several different methods of software protection that can be applied to a cryptographic process. This standard does not 
mandate, reguire, or endorse any particular method. However, this standard is created with the expectation that cryptographic keys 
used to secure the MPoC Solution are securely stored and managed. The tester is expected to review the implementation and methods 
used to inform the testing of the robustness of these methods, so that there is confidence they provide robust protection of cryptographic 
process and sensitive assets they protect. 
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Objective: Software-protected cryptography, where used, provides sufficient protection to the cryptographic keys it protecis. 


1B-2.1 Cryptography protected with 1B-2.1.a The tester must confirm through Clear information is reguired to outline how each 
software-only means must be examination that the provided information is cryptographic key is protected so that coverage can be 
documented. complete based on the tester's understanding of the | confirmed to be comprehensive, and flaws can be 
MPoC SDK. The information must include at a identified easily. 
mulim um. For this reguiremeni, it is reguired that the information 
» (Which keys are secured using software- provided covers all cryptographic keys that would 
protected cryptography, in whole or in part. otherwise be exposed in cleartext within the memory of 


the REE of the COTS device were it not for the 


What algorith implemen , ç 
- e erinin ere pp oriceeei apeme implementation of software protection methods. 


by the software-protected cryptography system 
used. 


» How many instances of software-protected 
cryptography are present for each algorithm. 

» The security mechanisms present in the 
software-protected cryptography. 

» The key hierarchy of the keys protected by 
software-protected cryptography. 


1B-2.2 The software-protected 1B-2.2.a The tester must confirm through Implementations of software protected cryptography are 
cryptography implementation must not examination that the software-protected intended to protect the cryptographic keys used. 
implement operations that expose, or cryptography operations present in the MPoC SDK Protections that apply only to some aspeci of the 
provide access to, cleartext cryptographic | do not expose, or provide access to, cleartext implementation, or that implement operations that may 
keys, key components/shares, or the cryptographic keys, or key componenits/shares. expose the cryptographic keys, are not sufficient for use 
intermediate results of a cryptographic with MPoC SDK. 

operation. For example, a software protected cryptographic 


implementation that does not sufficientiy protect key 
related values during operation, or only provides 
protection when the cryptographic process is not actualiy 
being executed, are insufficient. Similariy, 
implementations that may provide a key export feature 
that allows for exposure of cleartext keys or componenis 
are not sufficient. 
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1B-2.3 The software-protected 
cryptography implementation must not 
implement unnecessary operations. 


Test Reguiremenis 


1B-2.3.a The tester must confirm through 
examination and observation that the 
implementation of software protected cryptography 
within the MPoC SDK only implemenis the 
operations reguired. 


Guidance 


Usually, cryptographic implementations support at least 
iwo operations (e.g., encryption and decryption). If the 
MPoC SDK needs only to encrypt data before sending it 
to the backend, the decryption operation is not reguired to 
be present in the MPoC SDK, since it helps reverse the 
encryption operation and may pose an additional security 
risk. 


1B-2.4 The software-protected 
cryptography implementation, where it 
exists, must be replaced before the 
estimated time needed to break the 
implementation. Replacement must 
include changing of any cryptographic 
keys, or other assets, within the software 
protected cryptographic implementation. 


1B-2.4.a the tester must document an estimated 
exploitation time needed for an expert attacker with 
physical access to the COTS device to break any 
software-protected cryptography implementations 
used. 


1B-2.4.b The tester must confirm through 
examination that the update cycle for the software- 
protected cryptography is shorter than the time 
needed to perform a successful attack on that 
implementation. 


The tester may use the results from the previous attack 
testing on the software-based cryptography 
implementations, to establish a time during which that 
implementation must be replaced to mitigate attacks. 


Software-protected cryptography may implemenit several 
unigue master storage keys, which can be rotated over 
time to reduce the elapsed time during which a single key 
is used. However, if an attack is mounted on a software- 
protected cryptography implementation, this is usually 
automated, and rotation of master keys is of little use. 
Therefore, to defeat automation, the software-protected 
cryptography binary is reguired to be changed before the 
time estimated to extract keys from the implementation. 


The update of the software-protected cryptography binary 
may be implemented by updating the internal 
mathematical algorithm, its compiled binary structure, or 
its security mechanisms (obfuscation, anti-emulation, anti- 
DFA, encoding methods, etc.). The goal of the update is 
to impede the progress made by an attacker on the 
implementation. 


1B-2.5 The software-protected 
cryptography implementation must 
support secure key generation and key 
management processes. 


1B-2.5.a The tester must confirm through 
examination, observation, and interview (where 
appropriate), that the software-protected 
cryptography implementation supports secure key 
generation and key management processes, 
including: 

» Dualconiroland split knowledge of keys. 


» (Key generation methods that ensure keys have 
at least the same enitropy as their effective key 
strength. 


This reguirement covers the implementation and support 
systems for any software-protected cryptography. 
Operation of those systems is covered under the 
operational reguiremenits of this standard. 


This reguirement does not enforce the manual handling of 
cryptographic keys (as key componenis). Proper of back- 
end HSMs may provide for dual control and split 
knowledge across the keys. 
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1B-2.6 Cryptographic keys deployed 
within a software-protected cryptography 
implementation must not be used for 
encryption of account data or 
secret/private cryptographic keys during 
transmission. 


Test Reguiremenis 


1B-2.6.a The tester must confirm through 
examination and observation that keys deployed 
through the software-protected cryptographic 
implementation are not used to encrypt account 
data or other secret/private cryptographic keys 
during transmission. 


Guidance 


Cryptographic keys contained within a software-protected 
cryptography implementation during deployment may be 


used to protect keys during storage on the COTS 
Platform, or to help secure initial provisioning. 


However, as the keys used in these implementations may 


be shared across many MPoC Applications, it is not 


acceptable to rely on software-protected cryptography 


mechanisms to secure account data or other 


cryptographic keys during transmission outside of the 


COTS Platform on which the implementation resides. 


1B-2.7 The software-protected 
cryptography must prevent the extraction 
of partial or complete cryptographic 
material to an attack rating of 25 points 
using the attack-costing framework in 
Appendix B. 


1B-2.7.a The tester must confirm through 
examination, observation, and testing that the 
software-protected cryptography implementation is 
protected against known attacks against software- 
based cryptography. 


If anti-lifting or anti-emulation mechanisms are in 
place, separately from the A&M systems, the tester 
must include the attempit to bypass these 
mechanisms into the costing. 


The software-protected cryptography needs to implement 
protections to help it resist the extraction of complete or 


partial cryptographic material. 


If the software-protected cryptography has a storage or 


transport key used to protect all other keys, the 


compromise of this key implies the compromise of the 


protected keys. This is of special concern if the 


storage/transport key is shared across different MPoC 


Software installations. 
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1B-2.7.b The tester must provide a costing of this The security of any software-protected cryptography 
attack based on the method outlined in Appendix B. | implementation is reliant upon periodic updates, which is 
Attack Costing Framework. This reguirement is validated in a separate reguiremenit. 
passed if the most feasible attack cannot be costed. | The intent of this reguiremenit is that the security of the 
for less than 25 poinis. software protected cryptography implementation is tested 


directiy. Therefore, this testing is to be performed without 
additional security controls such as A&M or anti-rooting. 
The vendor of the MPoC Software or Software Protected 
Cryptography implementation may need to provide a test 
artifact for the testing process. 


Costing of the attack must consider the difficulty of 
disabling these features, and any code-lifting or emulation 
that is reguired as part of the attack. Code lifting can allow 
for the extraction of the software-protected cryptography 
implementation so that it can be executed in an 
environment or context under the control of an attacker. 


Usually, this is done for analysis of the cryptographic 
implementation and if, successful, can permit fault 
injections, oracle attacks, etc. 


A successful attack need not recover the entire key — it is 
considered sufficient if the tester is able to demonstrate 
success at recovery of some subset of the key and justify 
that this can be scaled to full key recovery. 


Examples of attacks to be considered by the tester 
includes Side Channel Analysis (SCA) and Fault Injection 
(FI) attacks such as Differential Computation Analysis 
(DCA) and Differential Fault Analysis (DFA). 
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Attestation is the interaction between a verifier and a prover to determine the current security state/behavior of the prover based on data 
provided through measuremenis performed by the prover. For the purposes of this document, the prover is the MPoC SDK (or aspecis of the 
MPoC Application) executing on the COTS device, and the verifier may have multiple componenis executing locally on the COTS device and 
remotely in a back-end attestation and monitoring (A&M). 


The attestation data may be determined in various ways, such as through a health-check interface that can be accessed by the prover. 
Attestation provides necessary assurance to the verifier that established and expected security controls at the prover are in an acceptable 
state and have not been tampered with. Organizations developing A&M components are subject to these reguiremenis. 


There are two types of attestations in MPoC Solutions, where the goal is to assess the integrity of the MPoC SDK and MPoC Application, and 
where the goal is to assess the integrity of the COTS platform. 


It is a reguirement of this standard that the attestation system and monitoring system together form the attestation and monitoring (A&M). The 
attestation and monitoring (A&M) includes a back-end system that can interpret and respond to the attestation results (i.e., the attestation 
results are reguired to be monitored). The MPoC SDK can attest to the COTS platform or provide attestation results to be examined by an 
external system (such as the attestation and monitoring (A&M)). Additionally, some level of ongoing validation of the MPoC SDK and COTS 
platform is reguired both to supplement the intermittent communication with the remote attestation and monitoring (A&M), as well as to support 
offline paymenis (where applicable). However, as the MPoC SDK may be open to compromise this software cannot attesi itself at all times. 
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The attestation and monitoring (A&M) must cover the COTS platform, the MPoC SDK, and MPoC Application aspects present in the 


COTS device. 


Security Reguirements 


Test Reguiremenis 


Guidance 


Objective: The attestation and monitoring (A&M) covers all assets and processing of the MPoC SDK and MPoC Application throughout its lifecycle. 


1C-1.1 Documentation on the coverage 
of the attestation and monitoring (A&M) 
MUSİ eXİst. 


1C-1.1.a The tester must confirm through examination that 

the reguired information exists, including, but not limited to: 

» (What checks are included in the MPoC SDK 
attestation and monitoring (A&M) and, if applicable, 
which parts of their result are checked or verified. 

» Whatis covered by the checks (e.g., code, data, 
application, OS, cryptographic, etc.). 

» (When, where, and under which circumstances are 
ihese checks executed and validated. 

» İfa security mechanism covers code (€.g., 
checksums), which parts of the code are covered. 


1C-1.1.b The tester must confirm through examination that 


the A&M design has no exploitable design flaws, matches 
the tester understanding of the MPoC Software, and is 
able to deteci threats against an MPoC Solution. 


The attestation and monitoring (A&M) is a vital part 
of the overall security of an MPoC Solution and, 
therefore, the coverage provided by the attestation 
and monitoring (A&M) parts of the MPoC Software 
mut be clearly outlined. This information assists in 
the integration of the MPoC Software with both the 
MPoC Application, and any back-end systems used 
as part of the A&M services. 


In the context of this reguiremenit, the terminology 
“no exploitable design flaws” is to be considered in 
relation to the ability to exploit these flaws during an 
attack on the MPoC Solution. The tester is expected 
to consider the exploitability of any flaws during their 
production of attack costings during an evaluation. 


MPocC reguires that there are checks that are 
performed on-device at all times, as well as checks 
that may be performed only when the data is to be 
sent to the back-end attestation and monitoring 
system. It is important that the documentation 
indicates when and where any checks occur. 


1C-1.2 The A&M functionality must cover 
the complete lifecycle of the MPoC SDK 
and MPoC Application, starting from 
installation through decommission. 


1C-1.2.a The tester must confirm, through examination, 
that the A&M covers the following parts of the MPoC SDK 
and MPoC Application lifecycles at a minimum: 


» Deployment (installation) 
» (o Provisioning (enrollment, provisioning) 


» (Operation (application startup, transaction execution, 
PIN entry) 


» oDecommissioning (removal of the MPoC SDK or 
MPoC Application) 


The MPoC SDK or MPoC Application could 
potentially be compromised at any stage of its 
lifecycle. Therefore, it is necessary that the A&M 
covers the complete lifecycle of the software 
deployed to the COTS device(s). 


It is possible that for some lifecycle stages, the 
MPoC SDK or MPoC Application is not able to 
execute. However, platform features may be 
leveraged to protect these stages (e.g., during the 
deployment and decommission of the MPoC 
Application). 

Although applications often do not have any control 
over their deployment and decommissioning, 
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consideration during the design of the application 
can ensure that data is handled securely during 
these phases. The intent of this reguirement is that 
ihe A&M validates the correct operation according 
to the design so that deployment and 
decommissioning can be validated as having been 
performed securely. 


1C-1.3 The attestation and monitoring 
(A&M) checks must cover the entire 
security-sensitive MPoC SDK code and 
execution flows that handle assets. 


1C-1.3.a The tester must confirm through examination that: 


The MPoC SDK is protected by the attestation and 
monitoring (A&M) at run-time. 


The A&M checks provide coverage over all MPoC 
SDK code, execution flow, and assets. 


Some A&M validation checks are always active during 
execution of the MPoC SDK providing protection 
against rooting, and activation of developer or other 
COTS operating modes that may impact security. 


The A&M checks are reguired to be implemented at 
different execution points and be executed at 
different points in time to mitigate attempis to 
bypass or avoid the detection features. This helps to 
ensure that there is not a single point of failure for 
the A&M checks. 


A&M may involve different levels of checks. Some 
checks may be less intensive or involve cali-back 
checks, such as checking for the activation of 
developer options or enabling of accessibility 
features that expose eniry of PINs, and therefore 
can provide constant protection. Other attestation 
and monitoring (A&M) checks may be more 
intrusive and be possible only at intervals to prevent 
unwarranted interruptions to the paymeni- 
processing flow. 


However, the MPoC SDK is reguired to have some 
level of continuous A&M at run-time (e.g., it is not 
sufficient to run all A&M checks only at launch or at 
intervals that may allow for Time of Check Time of 
Use-based attacks). Such checks can be used to 
deteci rooting or activation of developer or other 
modes that may affect the security of the MPoC 
Software operation. 
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Security Reguiremenis 


1C-1.4 The A&M system must attest the 
COTS platform and MPoC Application / 
MPoC SDK. 


Test Reguiremenis 


1C-1.4.a The tester must confirm through examination that 
ihe A&M system covers the COTS OS and is able to verify 
its security state. Including validating, at least, the following 


information: 


If the COTS device is rooted, jailbroken, or 
operating in developer mode. 


Modifications or tampering attempt events of 
the MPoC SDK, MPocC Application and COTS 
execution environment. 


The version of the COTS OS, MPoC 
Application, and MPoC SDK, including 
detection of any rollback attempis. 


Details on the status of any COTS-native 
interfaces implemented by the MPoC SDK for 
account data collection. 


Details on the status of any COTS-native 
interfaces that may be used for account data 
collection, which are not implemented by the 
MPoC SDK. 


Guidance 


The A&M is reguired to provide assurance that the 
MPoC SDK is not running on a compromised COTS 
platform (e.g., rooted, jailbroken, etc.). Although the 
MPoC SDK can use its own checks to perform this 
verification, there may be value in providing data to 
ihe A&M backend for additional validation or 
updates to local checks. 


Some platforms provide their own attestation 
functions that cover some or all componenits of 
COTS platform and hardware. However, these 
attestation functions are not sufficient to attest the 
security and correct operation of the MPoC SDK 
(these validation reguiremenis are tested 
separately). 


The attestation policy (Covered in reguirement 3C- 
1.1) outlines the responses and actions to be 
performed based on the attestation results. This 
may vary on a per-Platform basis — e.g., a solution 
where the MPoC SDK resides entirely in a TEE or 
SE (so no sensitive assets are passed in cleartext 
through the REE) may not consider a rooted or jail- 
broken device to be a negative security impact. 


Similarly, detection of a roll-back of the COTS OS 
may not necessarily result in immediate response 
from the A&M system, but may instead be noted 
and used in correlation with other signals from that 
same COTS device to determine the appropriate 
action, in line with the Attestation and Monitoring 
policy. 

A COTS Platform may not be able to attest thata 
specific COTS-native interface is “secure,” and in 
such cases it may be sufficient for the attestation 
functions to validate that the interface is preseni, in 
good order, and not accessed by other applications. 


COTS platforms may provide their own logging and 
monitoring of interfaces that could be used for the 
entry of account data. For example, an OS may log 
all traffic on the NFC or touch interfaces. The 
attestation policy and system baseline should 
consider and account for these COTS devices. 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0 
© 2022 PCI Security Standards Council, LLC. All rights reserved. 


November 2022 
Page 88 


» Security Li 
Standards Council 


Security Reguirements Test Reguiremenis Guidance 


Detection of any individual item of concern during 
an A&M check may not result in immediate 
disablement of payment acceptance. However, such 
detection will feed into the potential for escalated 
observation and analysis of that COTS device to 
confirm it remains a secure environment in which to 
continue the acceptance of paymenis. 


November 2022 
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1C-2 Measuremenis/Detection 


To perform attestation, the A&M component measures the COTS platform, MPoC Application, and MPoC SDK. Some or all of these 
measuremenis are communicated to the A&M backend for analysis and action. The guality and ability of the attestation and monitoring 
(A&M) to deteci potential attacks are bound by the type of measuremenis collected by the A&M backend, along with the analysis 
performed on those measuremenis. A&M systems are expected to incorporate knowledge across a population of COTS devices, 
enhancing the detection methods. 


Security Reguiremenis 


| Test Reguiremenis 


Objective: Sufficient information is collected to detect and mitigate threats to the MPoC Solution. 


Guidance 


i 1C-2.1 The information that is collected 
for attestation and monitoring purposes 
must be documented. 


1C-2.1.a The tester must confirm through 
examination that the data collected for A&M 
purposes includes sufficient information to attest the 
COTS platform, MPoC Application, and MPoC SDK, 
and identify any attached devices. 


1C-2.1.b The tester must confirm through 
examination and observation that the A&M data is 
uniguely assignable to the COTS device from which 
it originates. 


Knowledge of the signals collected from the COTS device 
is needed to develop the A&M service properly and 
assess the guality of the A&M. 


This reguirement includes information collected on the 
COTS device for A&M purposes and is not related directiy 
to security checks (e.g., COTS device model, OS version, 
etc.). 


A&M data where the COTS device or MPoC SDK is the 
prover may be assignable to that COTS device based on 
the method of collection (i.e., the signals collected can 
only have come from that COTS device). 


A&M data transmitted to the back-end A&M is reguired to 
be uniguely assignable to the COTS device from which it 
originated. This may be based on the cryptographic 
methods used to transmit that data and may use 
hardware-backed features present on the COTS platform, 
like hardware-backed keystores. 


Unigue assignment is reguired so that actions performed 
in response to the data collected can focus on the specific 
COTS device to which that data relates. This does not 
preclude the anonymizing of collected data to enhance 
future A&M processing. 
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Security Reguiremenis 


1C-2.2 The A&M data must reflect the 
current state of the MPoC SDK, MPoC 
Application, COTS platform, and 
peripheral devices, in addition to any 
security relevant changes or 
measuremenis that have occurred since 
the last communication to the A&M 
backend. 


Test Reguiremenis 


1C-2.2.a The tester must confirm through 
examination and observation that the A&M data 
seni to the A&M backend reflects the current state 
of the MPoC SDK, MPocC Application, COTS 
platform, and peripheral devices, in addition to any 
security relevant changes or measuremenis that 
have occurred since the last communication to the 
A&M backend. 


1C-2.2.b The tester must confirm through 
examination and observation that any cached or 
historic A&M data is maintained in a manner that 
protecis its integrity and authenticity. 


1C-2.2.c The tester must confirm through 
examination and observation that any cached or 
historic A&M data is unable to be used to replace or 
subvert the most recent and accurate data reflecting 
ihe current state of the MPoC SDK and MPoC 
Application. 


Guidance 


The measuremenis sent to the A&M backend are 
reguired to refleci the current state of the solution. Stale 
measurements may provide a false sense of security or 
be used by an attacker to replace more current data. 


However, an attacker may attempi to perform attacks 
during the window of time between communications to the 
A&M backend, so that their attacks go undetected. 
Therefore, in addition to ensuring the most current data, it 
is important that any security relevant A&M data is also 
transmitted to the backend when communication İS 
performed. 


1C-2.3 The A&M data sent to the backend 
must contain a freshness indicator. The 
A&M data and the freshness indicator 
must be protected against tampering. 


1C-2.3.a The tester must confirm through 
examination and observation that: 


» Mechanisms exist that provide freshness. 


»e The A&M dataandfreshness indicator is 
protected against tampering. 


The A&M needs to resist replay, preplay, or tampering 
attacks. 


The data providing freshness to the attestation system 
needs to be protected against tampering (e.g., the use of 
a signed timestamp or nonce known beforehand to the 
A&M backend). 


1C-2.4 The A&M functionality must 
include an aspect within the MPoC SDK, 
which performs continual monitoring. 


1C-2.4.a The tester must confirm through 
examination and observation that the A&M functions 
include checks that execute at all times when the 
MPoC Application is executing. This must include, 
at a minimum, checks for developer and debug 
modes where these features are available. 


On-device attestation can be time and resource intensive, 
and therefore full attestation checks cannot be continually 
performed. However, some checks are less intensive — 
such as the check for entry into developer mode, or 
activation of debug functionality — and can be more easily 
performed in the background at all times. 


To ensure the security of the MPoC Solution, it is 
important that the checks which are more easily deployed 
at all times, are not left until a full attestation is reguired. 
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1C-3 Response 


The A&M must be able to respond to potential attacks that it has identified. The response process, and the data that may lead to that 
response, must be documented. Attacks detected by the COTS-based A&M must be reported to the A&M backend. 


Security Reguirements | Test Reguiremenis | Guidance 
Objective: The A&M must be able to provide suitable responses to mitigate potential attacks. 
1C-3.1 Documentation must exist that 1C-3.1.a The tester must confirm through The A&M system needs to implement actions when i 
describes the actions that can be taken if | examination that the provided information is tampering of the MPoC SDK or MPoC Application is 
the attestation and monitoring (A&M) sufficient and consistent with the tester's detected. 
indicates that the MPoC SDK, MPoC understanding of the solution. Information outlining the functions provided by the 
Application, or COTS platform is attestation and monitoring (A&M) to indications of 
potentialiy compromised. 1C-3.1.b The tester must confirm through compromise is reguired. It is likely that the attestation and 
examination that ihe documeniation includes monitoring (A&M) backend is able to be configured to act 
potential configuration, or options for these actions in different ways and, where this is possible, the 
must also be documented. documentation needs to reflect how such configuration is 
managed securely. 
Common responses from the attestation and monitoring 
(A&M) include account deactivation, assets deletion, and 
temporal suspension until a manual verification OCcurs. 
Checks that attempi to validate the integrity of the COTS 
platform are included in this reguirement. Such checks 
may include validating that the COTS device has not 
been rooted, jailoroken, or otherwise compromised so 
that there is no longer a secure platform on which the 
MPoC SDK can execute. 
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Security Reguiremenis 


1C-3.2 Potential tampering events 
detected by the MPoC SDK must be 
reported to the attestation and monitoring 
(A&M) backend. 


Test Reguiremenis 


1C-3.2.a The tester must confirm through 
examination and observation that the MPoC SDK is 
able to report any potential tampering evenis to the 
A&M backend. 


Guidance 


A tamper attempit is detected by the MPoC SDK, it is 
reguired that the MPoC SDK informs the A&M backend. 
This can assist with the understanding of risk for similar 
iypes of solutions, as well as helping the A&M responses 
to be further tuned or developed to accommodate similar 
iypes of attacks. 


Additionally, as the MPoC SDK is considered to execute 
in a potentially hostile environment, communication of 
potential tamper events assists in aligning back-end 
responses with expected responses from the MPoC SDK. 
For example, if an MPoC SDK instance detects an 
attempted compromise and performs actions to halt 
payment processing, further paymeni processing from 
that instance received by the back-end system should be 
considered suspeci. 


i 1C-3.3 It must be possible for the MPoC 
SDK to disable processing in the event of 
tamper indications. 


1C-3.3.a The tester must confirm through 
examination and observation that the MPoC SDK is 
able to respond independenily to potential tamper 
events detected by local A&M checks. 


1C-3.3.b The tester must attempi to trigger a subset 
of the security mechanisms of the MPoC SDK and 
verify that the actions taken by the MPoC Solution 
are as documented. This test must be performed 
both with and without connection to the A&M 
backend to confirm that independent action is 
possible. 


Note: This testis not to verify the attestation policy, 
but to verify that the documented response 
capabilities exist in the MPoC Solution and can be 
iriggered. 


The ability to respond to potential attacks is a reguirement 
even during any loss of communication with back-end 
A&MSs. 


Tampering events may include both direct attacks on the 
MPoC SDK, such as detection of overlay during PIN 
entry, as well as compromises of the integrity of the 
COTS platform, such as rooting, jailbreaking, etc. 
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Security Reguiremenis Test Reguiremenis Guidance 
1C-3.4 The MPoC SDK must perform an 1C-3.4.a The tester must confirm through When not operating in offline paymeni-processing mode, 
attestation with the A&M backend upon examination and observation that the MPoC SDK tihe MPoC SDK is reguired to receive communications 
start up and at least every 60 minutes of prevenis further paymeni processing after 60 from the A&M back-end component at least every hour to 


continuous operation or suspend further minutes of continuous operation without a passing ensure that the MPoC Solution is operating securely and 
payment processing until such attestation | response from the A&M back-end component when | thatthe MPoC SDK has passed all attestation checks 
is performed. not operating in offline payment acceptance mode. successtfuliy. 


In the context of this reguiremeni, a “passing response” 
from the A&M back-end component indicates that the 
A&M system has performed and validated all attestation 
checks reguired by the MPoC Software attestation policy. 


This reguirement does not supersede any other 
reguiremenis for consistent A&M monitoring or checks to 
be performed on execution or prior to specific functions 
such as PIN entry. 


This reguirement does not replace reguirement 1C-2.4, 
which notes the need for the MPoC SDK to perform 
continual and ongoing checks at all times (although these 
checks may be a subset of a “full” attestation process 
performed locally). 


1C-3.5 An MPoC SDK that is suspended 1C-3.5.a The tester must confirm through An attacker may attempit to exploit periods of no 
or otherwise halted must perform an A&M | examination and observation that an MPoC SDK execution, or suspension of the MPoC SDK, to perform 
attestation prior to any payment resumed from a suspended, halted, or other mode attacks on the COTS platform. In such instances it is 
processing. that prevenis execution, reguires an A&M important the security and integrity of the platform is 
attestation process is performed prior to any validated prior to any paymenit processing. 
paymeni processing. When assessing this reguirement, the tester should 


consider how the COTS platforms supported by the 
COTS platform baseline operate with regards to 
application switching and halting. Some platforms may 
allow for continued secure operation when an application 
is not currentiy in focus or may allow for multiple 
applications to have presence on the display at any one 
time (e.g., during multi-tasking or multi-window operation). 


The MPoC reguirements allow for both remote and local 
attestation functions, and the type of attestation to be 
performed upon return to an MPoC SDK that has been 
removed from focus may depend upon the COTS 
platform features, and attestation methods implemented 
in local and remote operation. 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0 November 2022 
© 2022 PCI Security Standards Council, LLC. All rights reserved. Page 94 


» Security Li 
Standards Council 


Security Reguiremenis 


1C-3.6 A&M results that may reguire the 
cessation of paymenit acceptance must 
not be communicated through the COTS 
device. 


Test Reguiremenis 


1C-3.6.a The tester must confirm through 
examination and observation that any A&M results 
that may reguire the cessation of payment 
acceptance are not communicated from the A&M 
backend to the payment processing backend 
through the COTS device. 


Guidance 


A&M results that indicate that the payment acceptance 
must be halted are likely to result from a compromised 
COTS device or MPoC Application. This may impact the 
ability for the payment backend to receive accurate and 
correct data from the COTS device. 


This reguirement does not prevent or preclude 
operational models that provide the MPoC SDK with 
explicit approval to perform paymenis on a per- 
transaction basis. 
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1C-4 Anti-Tampering 


The MPoC SDK is protected against tampering through the utility of the A&M system. For this reason, the attestation and monitoring 
(A&M) is a high-value target for attackers and becomes a critical target that needs to be protected against tampering. 


Security Reguirements | Test Reguiremenis | Guidance 


Objective: The attestation and monitoring (A&N/), including the collection and transmission of data on the COTS device, is protected from compromise. 


1C-4.1 The protections provided to the 1C-4.1.a The tester must confirm through Modification of the attestation and monitoring (A&M) data 
attestation and monitoring (A&M) mustbe | examination that the information provided or code may, in practice, allow for the bypass of the 
documented. sufficientiy details the anti-tamper protections that security mechanisms. The A&M component on the MPoC 


have been validated through the MPoC SDK testing | SDK needs to be protected against tampering. 


process. Documentation is reguired to indicate what protections 
are provided, so that these can be confirmed as in-place 
during the lab validation. 
1C-4.2 A secure channel must not be 1C-4.2.a The tester must confirm through The modification of the messages between the A&M 
relied upon as the sole protection for A&M | examination and observation that the data component on the MPoC SDK and the A&M backend may 
data during transmission. transmitted between the A&M functions in the MPoC | hinder the detection of tampering events on the backend 
SDK and the A&M backend is protected for and interfere with the monitoring of the MPoC Solution. 
authenticity and integrity, separately to the Hence, the authenticity and integrity of ihe messages 


protections provided by the secure channel used for | needs to be guaranteed. 


that connection. The reguirements in 1A-5 outline the need for all 
connections to implement secure channels and the 
security properties of these channels. This reguirement 
covers the need to protect the A&M data within the secure 
channel itself — use of a secure channel as the sole 
method of protection for A&M data integrity and 
authenticity is not sufficient. 


The secure channel may be religed upon to provide the 
confidentiality protections for this data, as the primary 
concem is that the data is altered rather than disclosed. 


The A&M messages contain sensitive assets such as 
security check results. sensitive assets can be abused to 
reverse engineer the security mechanisms in the MPoC 
SDK. Hence, confidentiality is needed to protect the A&M 
messages. 
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Security Reguiremenis 


1C-4.3 The local time source used by the 
MPoC SDK must be secured against 
tampering or alteration. 


Test Reguiremenis 


1C-4.3.a The tester must confirm through 
examination and observation that the local time 
source İS protected against tampering. 


1C-4.3.b The tester must confirm through 
examination and observation that the local time 
source is validated during connections to the back- 
end A&Ms. 


Guidance 


The time source used to track the local time is reguired to 
be reliable and trusted. The COTS platforms and MPoC 
Solutions may offer different options of measuring time. 
The MPoC SDK is reguired to select the option that 
reflects real elapsed time to enforce the time limits 
properiy. For example, time may be provided by a PCI 
PTS SCRP during each transaction. In these cases, the 
tester is expected to validate that interaction with the PCI 
PTS SCRP is reguired for each transaction. 


Timers used for this purpose need to be monotonic, and 
clock sources, if used, need to prevent or log alteration by 
applications or users. If the clock value could be affected 
by, or altered during, sleep evenis or periods when the 
MPoC SDK is not executing, paymenit processing must be 
prevented after such events until connectivity to the back- 
end system can be re-established and the offline payment 
data cleared. 


Validation of the local time source during connections to 
the attestation and monitoring (A&M) helps to identify 
attacks that may attempt to manipulate this source. 
Additionally, it helps to ensure that the attestation and 
monitoring (A&M) can correctly and accurately interpret 
any time stamps used in transmitted attestation and 
monitoring (A&M) data. 


1C-4.4 The A&M backend must be able to 
deteci failures in the A&M functions within 
the MPoC SDK. 


1C-4.4.a The tester must confirm through 
examination and observation that the A&M backend 
is able to detect and respond to failures in the 
MPoC SDK A&M functions. 


The A&M backend is reguired to monitor and be able to 
respond to situations where there is an indication of 
failure in the MPoC SDK. For example, if attestation data 
is repeated when it should not be, or is not present, when 
the MPoC SDK appears to be continuing to transaci, it 
may be an indication of an attack on the paymeni system. 
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Security Reguiremenis 


1C-4.5 The A&M used by the MPoC SDK 
must be resistant to tampering to an 
attack rating of 25 points using the attack- 
costing framework in Appendix B. 


Test Reguiremenis 


1C-4.5.a The tester must test the MPoC SDK by 
attempting to tamper with the attestation system and 
the messages sent and received from the 
attestation and monitoring (A&M) backend. 


1C-4.5.b If security mechanisms preveni the 
tampering, the tester must attempit to bypass the 
mechanisms. If it is not possible to bypass the 
mechanism, the tester must describe what would be 
needed to bypass the mechanism successtfuliy (the 
expected actions/situations needed to bypass the 
mechanism). 


1C-4.5.c The tester must provide a costing of this 
attack based on the method outlined in Appendix B. 
Attack Costing Framework. This reguirement is 
passed if the most feasible attack cannot be costed 
for less than 25 points. 


Guidance 


The A&M plays the important role of communicating the 
security state of ihhe COTS and PCI PTS SCRP devices to 
the backend and concentrating the security information of 
the MPoC SDK. A compromise of the attestation and 
monitoring (A&M) component on the COTS device or data 
transmitted to the backend may be the same as 
effectively disabling security checks. 
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1C-5 A&M Integration Guidance 


The attestation and monitoring (A&M) needs to be integrated securely into the MPoC Solution. Therefore, it is important to ensure that 
information exists that facilitates the transfer of the security and operational knowledge reguired. 


Security Reguirements 


Test Reguiremenis 


Guidance 


Objective: Sufficient guidance and features are provided to allow for the secure integration and operation of the attestation and monitoring (A&M). 


1C-5.1 A&M back-end operation security 
guidance information must exist that 
explains how the attestation and 
monitoring (A&M) is securely configured 
and operated. 


1C-5.1.a The tester must confirm through 
examination that the attestation and monitoring 
(A&M) back-end operation security guidance 
contains the reguired information and comment on 
its sufficiency to securely configure the attestation 
and monitoring (A&M) backend according to the 
tester's understanding of the MPoC Software. The 
documentation must include the following at a 
minimum: 
» How to configure the attestation and monitoring 
(A&M), including the offline policy, securely. 


» A baseconfiguration for the attestation and 
monitoring (A&M). 


» (o Specific integration reguiremenis that must be 
fulfilled to integrate the attestation and 
monitoring (A&M) component securely. 


1C-5.1.b The tester must confirm through 
examination that the attestation and monitoring 
(A&M) security guidance includes a base 
configuration defined for the A&M component. This 
configuration is assumed to be a secure 
configuration for the A&M and must be the one used 
for the PCI MPoc validation tesis. 


This information is reguired even when the attestation and 
monitoring (A&M) is operated by the developer of that 
system, as correct operation reguires proper levels of 
training and documentation. It is not sufficient for 
operation of an attestation and monitoring (A&M) 
environment to rely entirely on experience and knowledge 
that is not otherwise documented. 
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Security Reguiremenis Test Reguiremenis Guidance 
1C-5.2 The security guidance information | 1C€-5.2.a The tester must confirm through Integration of the A&M functionality is reguired for all 
must detail how to securely integrate the examination that the security guidance includes ata | MPoC implementations. This security guildance may bea 
A&M software component into the MPoC | minimum: formal document for MPoC Software componenits that are 
Application. e — How todeploythe A&M software component in to be operated by third parties, or internal knowledge 
a production-ready configuration (€.g., not base solutions for vendors performing all operations 
debugging enabled). reguired of an MPoC Solution. 


» Howtointegratethe A&M software component 
into the MPoC Application. 

» (o Specific dependencies of security checks on 
OS versions or COTS platforms. 


1C-5.3 Security guidance information 1C-5.3.a The tester must confirm through An A&M can be configured at run-time or compile time. 
must detail what A&M features are examination that the configuration options of the Documentation that clearly states what signals and 
configurable, the processes for setting or A&M are documented, including their possible responses are configurable, and which ones are not, help 
changing these configurations, and how settings. understand the baseline security of the solution and work 
ihe applicable settings may affect the as an input for policy making. 
security and functionality of the overali 1C-5.3.b The tester must confirm through Sufficient information needs to be provided over the 
MPoC Solution. examination that the configuration options existand | configuration of the A&M component, such that it can be 
are limited to the documented options. configured properly during integration and so the impact 


of such configuration decisions can be understood. 
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Module 1D: Secure Entry and Processing of Account Data 


This Module covers the use of external and/or COTS-native systems to read payment account data from a payment instrument such asa 
payment card. This Module does not cover the entry of account data not obtained from the payment instrumenit, such as PINs. This Module 
includes reguiremenis for the use of PCI PTS SCRP devices, non-PTS approved MSR devices, the use of the COTS-native NFC interface to 
read contactless payment instruments, and manual eniry of account data. 


Only account data entry systems specifically addressed by this standard may be used within an MPoC Solution. Future updates to this 
standard may include or support other methods of account data entry. 


1D-1 Account Data Eniry and Encryption 
This Section covers the reguiremenits for all COTS-native account data entry methods, and how this data must be secured as it İS 
entered and processed. These reguiremenis do not apply to data captured through a PCI PTS SCRP or non-PTS approved MSR 
device. 

Security Reguiremenits | Test Reguiremenis | Guidance 


Objective: All account data entry methods are documented and provide encryption for onward processing 


1D-1.1 Documentation must exist that 1D-1.1.a For each of the account data entry It is a reguirement that all account data eniry methods 
details how account data is entered and methods supported by the solution, the tester must that the MPoC SDK supports are understood and secured 
secured. confirm through examination that the reguired properiy. Use of functionality that has not been assessed 
information for integration with the MPoC SDK is presents a security risk to the MPoC SDK. 
present. Documentation associated with any external or add-on 
The information must provide details about: account data entry methods needs to contain all the 


necessary information to integrate that system securely 


All methods used for the entry of account data 
ği , ” into the MPoC Solution. 


into the MPoC SDK. 

» (The supportedfunctionality of each account 
data entry method. 

» — All guidancereguiredfor the correct and 
approved operation of any of the account data 
entry methods. 
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Security Reguiremenis 


1D-1.2 Account data must be encrypted 
at the earliest possible point. Account 
data provided from acceptance devices 
external to the COTS device (such as 
from a PCI PTS SCRP or non-PTS 
approved MSR device) must be provided 
encrypted and not be decrypted on the 
COTS platform. 


1D-1.3 Secret or private cryptographic 
keys related to account data protection 
must never be stored as cleartext in non- 
volatile storage within the REE of the 
COTS device. 


Test Reguiremenis 


1D-1.2.a The tester must confirm through 
examination that for any account data eniry 
methods implemented on the COTS device, the 
card data is encrypted either immediately upon 
entry or immediately after any reguired processing 
through associated payment kernels. 


1D-1.2.b The tester must confirm through 
examination and observation that account data 
provided by acceptance devices external to the 
COTS device, such as PCI PTS SCRPs or non-PTS 
approved MSR$, is received encrypted and the 
cryptographic keys reguired to decrypt this data are 
not available on the COTS device, and the cleartext 
account data is never returned to the COTS device. 


1D-1.3.a The tester must confirm through 
examination and observation that any secret or 
private keys used for encryption of account data are 
not stored as cleartext in non-volatile storage within 
ihe REE of the COTS device. 


Guidance 


Account data is reguired to be encrypted at the earliest to 
reduce the opportunity window in which account data can 
be compromised in cleartext. Normally, this is done in the 
external card reader itself or in the MPoC SDK when a 
COTS native interface, such as COTS-native NFC, is 
used. 


Although it is not the scope of this reguiremeni to assess 
the encryption of any external account data capture 
systems, such as a PCI PTS SCRP or non-PTS approved 
MSR, the assessor is reguired to confirm that there is no 
functionality on the COTS device that would expeci this 
data to be provided in cleartext or allow for the decryption 
of the account data on the COTS platform. 


Account data encryption is reguired to be provided 
separately from any secure channels provided. 
Encryption of account data by the secure channel, such 
as through the use of TLS, is not sufficient to meet this 
reguirement. Datagram-level encryption using encryption 
keys dedicated to account data encryption needs to be 
used. 


Account data-related keys are not permitted to be stored 
in cleartext on the COTS platform. This includes any keys 
used to derive the unigue per transaction key that directly 
encrypts the account data. Use of a hardware-backed 
keystore to maintain the account data-related keys may 
assist in providing security over key storage to meet this 
reguirement. This is assessed as part of the key 
management reguiremenis. 


Encryption needs to use suitable cryptography as 
assessed in Section 1A-3, and use suitable key 
management as assessed in Section 1A-4. 


DAA Cryptographic keys usedto 
encrypt account data must be unigue per 
MPocC Application installation. 


1D-1.4.a The tester must confirm through 
examination and observation that any cryptographic 
keys used to encrypt account data are unigue per 
MPocC Application. 


Where cryptographic keys are shared across different 
systems, the risk of compromise for those keys increases. 
To ensure that the compromise of any one MPoC 
Application does not affect the security of any other 
MPoC Application, the cryptographic keys used to encrypt 
account data must be unigue to each instance of an 
installed MPoC Application (not just unigue to a particular 
MPocC Application version). 
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Security Reguiremenis 


1D-1.5 Account data encryption keys 
exposed in the rich execution 
environment of the COTS device must be 
unigue per transaction and implement 
perfect forward secrecy. 


Test Reguiremenis 


1D-1.5.a The tester must confirm through 
examination and observation that if any 
cryptographic keys related to account data 
encryption are exposed in the rich execution 
environment of the COTS device, those keys are 
implemented using a unigue key per transaction key 
management method. 

Note: This reguirement applies if the keys are ever 
€xposed in cleartexi, regardless of the operations or 
functions being performed at that time. 


Guidance 


Although cryptographic keys related to account data 
security are reguired to never be stored in cleartext within 
the rich execution environment, these keys may be 
exposed in the rich execution environment as cleartext 
during cryptographic operations. 

Where this occurs, it is important that the increased risk of 
exposure of these keys is mitigated by ensuring that the 
keys are unigue per transaction and implemeni perfect 
forward secrecy. 

There should not be sufficient information left within the 
MPoC SDK or COTS platform to decrypt the account data 
after it is encrypted or to reconstruct the keys used to 
encrypt the data. 


1D-1.6 The disclosure of a secret or 
private key used for account data 
encryption must not leak any sensitive 
information of the key values for past or 
future keys. 


1D-1.7 The MPoC SDK must truncate or 
mask the PAN, using methods compliant 
to relevant PCI DSS FAOs, when 
outputting or displaying PAN data that is 
not encrypted. 


1D-1.6.a The tester must confirm through 

examination that the process used for generation of 
account data encryption keys is secure, and that the 
disclosure of a key used for account data encryption 
does not leak any information of past or future keys. 


1D-1.7.a The tester must confirm through 
examination and observation that the PAN is 
appropriately truncated or masked when output or 
displayed (e.g., by using the COTS device screen or 
printing a receipt) according to the relevant PCI 
DSS FAS. 


1D-1.7.b The tester must confirm through 
examination and observation that the MPoC 
Software does not provide functions to display 
cleartext cardholder data that is not truncated or 
masked. 


The process used to generate and distribute account data 
encryption keys is not permitted to expose or increase the 
chance of compromise for any prior or future keys. For 
example, any derivation process needs to be one way. 


Use of DUKPT key management may be sufficient to 
meet this reguirement, depending upon the 
implementation. 


Customer receipts may be necessary for customer 
validation of the transaction and as part of a formal 
payment challenge process. When such data is sent from 
ihe back-end environment for display or printing in the 
merchant environment, any PAN data on the receipit is 
reguired to be truncated to ensure that it cannot be 
uniguely correlated with the customer and that full details 
are not available to the merchant. 


Functions to display cardholder data, either during or post 
transaction processing, could be used to facilitate the 
disclosure and compromise of this data. The MPoC SDK 
can display PAN data that is truncated or masked as per 
relevant PCI DSS FAOs. The intent of truncation is to 
remove a segment of PAN data permanently, so that only 
a portion of the PAN is available on the COTS device. 
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Security Reguiremenis 


1D-1.8 The MPoC SDK must be able to 
deteci and respond to events that may 
impact the security of the card data entry 
process. 


Test Reguiremenis 


1D-1.8.a The tester must confirm through 
examination and observation that the following 
evenis trigger a response that maintains the security 
of the card data entry process: 


» (Another application overlays the MPoC SDK. 
» The MPoC SDK pauses or stops executing. 
» The MPoC SDK losesits foreground focus. 


Guidance 


The transaction process needs to be protected against 
manipulation or subversion. Attempts to modify or overlay 
the cardholder prompts (e.g., instructions to the 
cardholder) or other Ul features that are important for the 
security of the solution are reguired to be prevented. 
Pausing the application usually means that the application 
remains partially visible while the user interacts with a 
different dialog or screen (e.g., in multi-screen mode). 


When the user switches to a different application, the 
application is considered “stopped” until either the user 
switches back or the system destroys the instance of the 
application. 


Although account data entered through external devices 
like a PCI PTS SCRP is encrypted prior to transmission 
outside of that device, designs need to consider the 
security implications of pausing or changing application 
focus. For example, interception or interruption of the 
communications path between the MPoC Software anda 
PCI PTS SCRP should not allow for compromise of any 
account data or access to sensitive functions within the 
external card acceptance device. 


The security of the other applications on the COTS device 
is not known and therefore it needs to be assumed that 
the COTS environment may be hostile. 

In the context of this reguirement, a “response” is 
implemented based on the attestation policy of the MPoC 
Solution. 
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Security Reguiremenis Test Reguiremenis Guidance 
1D-1.9 The MPoC SDK must not store 1D-1.9.a The tester must confirm through Account data is permitted to be stored on the COTS 
account data for any purposes other than | examination and observation that account data is device only for the purposes of offline paymenits. This 
offline payment processing. not stored on persistent storage, excepi for the includes storage where the account data may be 
purposes of offline payment processing. protected through means such as encryption or storage in 


tamper-resistant processing elemenis. 


For the purposes of this reguiremenit, “storage” refers to 
any non-volatile or long-term memory, such as Flash or 
RAM discs. Temporary storage of data within the memory 
of the COTS devices is permitted; however, any such 
storage needs to be cleared securely as soon as 
possible—no later than when the transaction has been 
sent for processing. 

Support for offline processing and associated data 
storage is not mandatory and may be conditional or 
disabled as reguired. 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0 November 2022 
© 2022 PCI Security Standards Council, LLC. All rights reserved. Page 105 


» Security Li 
Standards Council 


1D-2 Use of PCI PTS POl-approved Devices 


If an external card reader is used to accepi chip-based transactions, or any type of contact-chip based transactions are to be accepted, 
the card reader used must be validated and listed as a PCI PTS SCRP. A PCI PTS SCRP must be used for any MPoC Solution that 
accepis contact chip-based paymenit cards, as well as for any offline PIN-based transactions. 


Security Reguiremenits 


| Test Reguiremenis 


| Guidance 


Objective: Secure card readers supported by the solution provide sufficient protection to account data. 


1D-2.1 Information must exist that details 
the secure card readers used by the 
solution. 


1D-2.1.a For each of the PCI PTS devices used in 
the solution, the tester must confirm through 
examination that the following information is 
provided at a minimum: 


» (Hardware, firmware, andlisting details for each 
PCI PTS device used. 


» (o Supported functionality of each secure card 
reader. 


» — All guidancereguiredfor the correct and 
approved operation of the used secure card 
reader. 


Any PCI PTS devices used with the MPoC SDK need to 
have been assessed for the specific use implemented in 
the MPoC SDK. Use of functionality that has not been 
assessed presents a security risk to the MPoC SDK. 
The documentation provided by the MPoC Software 
vendor needs to contain all the necessary information to 
integrate the PCI PTS SCRP securely into an MPoC 
Solution. 


1D-2.2 Any chip accepting devices must 
be approved to the PCI PTS POJ 
reguiremenis as a PCI PTS SCRP. 


1D-2.2.a The tester must document all chip 
accepting devices that can be used with the MPoC 
SDK, including the PCI PTS listing number and 
confirm that each is approved under the PCI PTS 
SCRP approval class. 


SCRP is a PCI PTS approval class that supports 
software-based PIN entry for chip transactions on a 
COTS device according to these reguiremenis. The use 
of PCI PTS SCRP devices not evaluated and listed by 
PCI may introduce security vulnerabilities in the MPoC 
Solution. 


1D-2.3 The PCI PTS POl| devices must be 
attested as part of the MPoC SDK 
attestation system. 


1D-2.3.a The tester must confirm through 
examination and observation of the A&M that: 


» Any PCIPTS devices used are uniguely 
identified and validated. 


» Thefirmware version is verified by the A&M. 


» Thestateofthe PCİ PTS device is verified by 
the A&M. 


» PCI PTS devices have the most recent firmware 
installed, as listed on the PCI PTS listing for 
that device. 


The A&M needs to ensure that all aspects of the MPoC 
SDK are operating as expected and are not in a state that 
indicates or could facilitate compromise. This includes 
validating the state and security posture of any attached 
card-reading devices. 


This validation included confirmation of the firmware 
version(s) of the attached devices, as well as hardware 
versions, and confirming that these are up to date with 
any relevant security patches — e.g., they are installed 
with the latest versions as shown on the PCI listing 
website. 
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Security Reguiremenis 


1D-2.4 Enablement tokens are reguired 
for continued operation of the PCI PTS 
SCRP and are provided to PCI PTS 
SCRPs only after successful attestation. 


Test Reguiremenis 


1D-2.4.a The tester must confirm through 
examination and observation that the back-end 
attestation and monitoring (A&M) component of the 
MPoC Software provides enablement tokens to the 
PCI PTS SCRP only after the PCI PTS SCRP has 
been validated successfully through an attestation 
process. 


1D-2.4.b The tester must confirm through 
examination and observation that a PCI PTS SCRP 
ceases the acceptance of account data if an 
updated enablemenit token is not received prior to 
the expiry of the previous token. The maximum 
period during which a PCI PTS SCRP may continue 
to accept account data without an updated 
enablemenit token must not exceed 24 hours. 


Guidance 


PCI PTS SCRP devices reguire a cryptographic token to 
be provided by the back-end system — without such a 
token provided before a predefined time limit, the PCI 
PTS SCRP will cease to permit the acceptance of 
paymenit cards. 


These tokens help to mitigate the risk of a local 
compromise on a COTS paymenit system, by providing a 
“cut-off” for payment acceptance using the PCI PTS 
SCRP if a valid token is not provided. 
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1D-3 Magnetic Stripe Data 


Magnetic stripe data may be read only through external devices listed as meeting the PCI PTS SCRP reguiremenis or as a Non-PTS 
approved MSR validated to the reguirements of Appendix E. 


Security Reguirements 


Test Reguiremenis 


Objective: Data from magnetic stripe cards is secured through approved readers. 


Guidance 


i 1D-3.1 Documentation must exist that 
details the MSRs used by the solution. 


1D-3.1.a For each of the devices used to accepit 
magnetic stripe transactions in the solution, the 
tester must confirm through examination that details 
about the following are provided at a minimum: 


» The hardware, firmware, and validation details 
for each MSR used. 


»* (The supportedfunctionality of each MSR. 


»e — All guidancereguiredfor the correct and 
approved operation of the used MSRs. 


Any MSR devices used with the MPoC SDK need to have 
been assessed for the specific use implemented in the 
MPoC SDK. Use of functionality that has not been 
assessed presents a security risk to the MPoC SDK. 


The documentation provided by the MPoC Software 
needs to contain all the necessary information to integrate 
any devices accepting magnetic stripe-based transactions 
securely into an MPoC Solution. This may include the use 
of PCI PTS SCRP devices as well as non-PTS approved 
MSR devices. 


Validation details may include reference to listing on a 
PCI validation list or assessment through the MSR 
Appendix. 


1D-3.2 Magnetic stripe cards are 
accepted only through readers listed as 
PCI PTS devices (Approval Class SCRP) 
or as Non-PTS Approved MSR. 


1D-3.2.a When magnetic stripe transactions are 
supported, the tester must confirm through 
examination and observation that only approved 
PCI PTS SCRP or non-PTS approved MSR readers 
are able to be used to accept magnetic stripe 
transactions that are processed online. 


1D-3.2.b The tester must document the validation 
and listing for any MSR Reader devices used with 
the MPoC SDK. Reguirements for non-PTS 
approved MSR devices are provided in Appendix E: 
MSR Security Reguiremenis. 


An MPoC SDK may accept magnetic stripe-based 
transactions using either a PCI PTS SCRP that integrates 
an MSR, or a dedicated Non-PTS approved MSR device. 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0 
© 2022 PCI Security Standards Council, LLC. All rights reserved. 


November 2022 
Page 108 


» Security Li 
Standards Council 


Security Reguiremenis 


1D-3.3 The MSR devices must be 
attested as part of the MPoC SDK 
attestation system. 


Test Reguiremenis 


1D-3.3.a The tester must confirm through 
examination that: 


» o Any MSR devicef(s) used are uniguely identified 
and validated by the attestation and monitoring 
(A&M). 

» Thefirmware version of any MSR devices) is 
verified by the attestation and monitoring 
(A&M). 

» Thestateofthe MSR device is verified by the 
attestation and monitoring (A&M). 


» The MSR devices(s) are confirmed by the 
attestation and monitoring (A&M) to have no 
known or exploitable vulnerabilities. 


Guidance 


The attestation and monitoring (A&M) needs to ensure 
that all aspects of the MPoC SDK are operating as 
expected and are not in a state that indicates or could 
facilitate compromise. This includes validating the state 
and security posture of any attached card-reading 


devices. 


Firmware in the context of this reguirement may include 
operational code that is executed by an underiying 
processor, or the version of a dedicated ASIC used in 


place of a general-purpose processor. 


1D-3.4 MSR data captured in an MPoC 
Solution must not be made available in 
cleartext on the COTS device. 


1D-3.4.a The tester must confirm through 
observation and examination that any MSR data 
captured is never exposed in cleartext within the 
COTS device. This includes validating that no 
optional configuration settings or functions exist that 
may disable or prevent encryption from the MSR 
itself. 


Data from a magnetic stripe card can be easily copied 
and replicated onto a “cloned” card for use in fraudulent 
transactions. To help mitigate against this risk, the data 
from the magnetic stripe is encrypted within the PCI PTS 
SCRP or non-PTS approved MSR device used and is not 


exposed in the COTS device. 
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10-4 COTS-Native NFC Interface 


Contactless payment instruments may be accepted through the COTS-native NFC interface of the COTS device. This interface may be 
open to all applications on the COTS device. Protections must be implemented to secure the account data as it is entered and to ensure 
that the data is encrypted as soon as possible after processing within any payment kernel. 


The contactless kernel has direct access to assets. Iherefore, the processing, memory, and storage used by this kernel must be 
protected to prevent the assets from being compromised when handled by the paymenit kernel. 


The reguiremenis in this Section apply to the COTS-native NFC interface only. 


Security Reguirements | Test Reguiremenits | Guidance 


Objective: Account data is protected and securely processed when it is read by the COTS-native NFC interface. 


1D-4.1 Information that details the 1D-4.1.a The tester must confirm the following Contactless kernels used by the MPoC SDK provide for 
implementation of the COTS-native NFC through examination: processing of account data. Therefore, the exact 
acceptance method, including the » o Thatall COTS-native NFC acceptance methods implementation and integration are important to the 
implementation for any contactless are detailed. overall security of the MPoC Solution. 

kernels, must exist. Contactless kernels need to be integrated in a way that 


» İfpartofthe kernel is executedremotely (e.g.,a 
cloud-based kernel), where and what parts of 
the kernel are included in this remote execution. 


» (Howthe kernelis configured and how the 
configuration is protected. 


» (How the kernel is secured against tampering. 


ensures they are protected against tampering (e.g., by 
being integrated as part of the overall tamper protection 
and response of the MPoC SDK). 


1D-4.2 The MPoC SDK must ensure that | 1D-4.2.a The tester must confirm through To prevent interference or interception of the COTS- 
tihe COTS-native NFC interface is not examination and observation that the MPoC SDK native NFC communication, the MPoC SDK needs to 
accessed by other applications during a implements mechanisms to prevent, monitor, or attempi to implement methods to preveni or detect 
paymenit transaction. otherwise inhibit access to the COTS-native NFC access to this interface by other applications during the 
interface by other applications during a payment paymeni transaction process. 
transaction. 


This may involve attempting to assert exclusive control to 
the COTS-native NFC interface before initiating the 
transaction, or monitoring if another application accesses 
ihe interface. 


The MPoC SDK needs to preveni transaction processing 
if it cannot provide a sufficient level of security to the 
COTS-native NFC interface. 
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Security Reguiremenis 


1D-4.3 The MPoC SDK must ensure that 
the COTS device camera(s) are accessed 
by other applications during a payment 
transaction. 


Test Reguiremenis 


1D-4.3.a The tester must confirm through 
examination and observation that the MPoC SDK 
implements mechanisms to prevent, monitor, or 
otherwise inhibit access to the COTS device 
camera(s) by other applications, during a payment 
transaction. 


Guidance 


The camera can be used as a side-channel source to 
gain access to assets such as CVC/CVV. 


To prevent unauthorized visual capturing of account data 
from a paymeni instrument, such as a payment card, 
when it is in proximity to the COTS device, the MPoC 
Application should attempit to prevent other applications 
and processes running on the COTS device from using 
ihe camera. 


The expectation is that other applications on the COTS 
device are not able to use the camera when the MPoC 
application prompts the cardholder to initiate a 
contactless paymeni, or that access by another 
application during this time is detected and the payment 
transaction halted. 


i 1D-4.4 Contactless kernels used in the 
MPoC SDK must be approved for use, as 
reguired by the relevant payment brands. 


1D-4.4.a The tester must confirm through 
examination that any kernel integrated into, or used 
by, the MPoC SDK has been approved by the 
supported payment methods. 


1D-4.4.b The tester must document the EMV/brand 


approval version and number for the contactless 
kernel and confirm through examination that the 
scope of the approval appears valid, given the 
tester's understanding of the solution under 
evaluation. 


The reguiremenis in this standard cover the security of a 
COTS-based acceptance solution. Validation that the 
payment process can be performed in a functionaliy 
correct and successful way is covered under the approval 
of the paymeni kernel. 


An MPoC SDK may implement more than one payment 
kernel, and may use kernels developed for the solution, 
3rd party kernels, and/or utilize remote kernel 
functionality. 


Payment kernels for non-PCI payment brands are not in 
scope of this reguiremenit. 


Some payment kernel functional evaluations may reguire 
the assessment of a complete transaction, e.g., “level 3” 
testing. An MPoC Solution may not have been processed 
through such functional testing prior to testing to this 
standard, and therefore this type of functional testing İs 
not considered in scope of this reguiremenit. 


1D-4.5 When part of the kernel 
functionality is implemented remotely, the 
connection between the MPoC SDK and 
the remote component must be protected 
using a secure channel. 


1D-4.5.a The tester must confirm through 
examination that the communication with remote 
componenis of the kernel is done through secure 
channels. 


ı 
For account data, protection using a secure channel is not 
considered sufficient, application-level encryption is 
reguired. 
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1D-5 Manual Entry 


Transactions using account data obtained from a manual eniry process may be processed by an MPoC Solution only when no PIN entry 
is performed, and when the manual data eniry process is protected. Entry of truncated PAN data, or data into software not executed on 
tihe COTS device, is not included in scope of these reguiremenis. 

Security Reguiremenits | Test Reguiremenis | Guidance 


Objective: Account data entered into the COTS device through manual entry methods is secured. 


1D-5.1 Documentation must exist that | 1D-5.1.a For each of the manual account data eniry An MPoC SDK may support manual eniry of the PAN, 
details the manual entry process and methods used in the solution, the tester must confirm e.g., to enable payment processing if other card 
protection methods. through examination that details about the following are presentment modes fail (due to a damaged chip or 
provided at a minimum: magnetic stripe). Additional account data, such as the 
» o The ways in which the manual entry method can be security code for the card, may be additionally reguired 
invoked. during such payment processing. 


It is important that any such methods of manual entry 


Th İ li h i N i 
e e are detailed to allow for a complete understanding and 


e o The iypes of account data that may be manualiy security assessment of these modes of data 
entered. presentment. 

1D-5.2 Manually entered account data | 1D-5.2.a The tester must confirm through examination An MPoC SDK is permitted to provide manual eniry for i 

must be used only for the purposes of | and observation that manually entered account data is account data only for the purposes of transaction 

transaction processing. used only for the purposes of transaction processing. processing. For example, manual entry of PAN data as 
a data element in a search of prior transactions is not 
permitted. 
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Security Reguiremenis 


1D-5.3 Manually entered account data 
must be protected during entry. 


1D-5.4 The manual PAN eniry 
currently in progress must be 
cancelled when MPoC SDK detecis 
another application overlays. 


Test Reguiremenis 


1D-5.3.a The tester must confirm through examination 
and observation the following for each of the manual 
account data eniry methods implemented: 


» The entry methodsdonot allow the storage of the 
account data. This includes by the OS for purposes 
such as speli-checking dictionary creation. 


» The account data is entered directly into the MPoC 
SDK. Third party keyboard or data entry applications 
are not used for account data entry. 


» (Entry modesdonotusenon-manual entry modes 
such as optical capture, through the COTS camera. 


» İtisnot possible to take screenshots or recordings of 
the MPoC SDK during PAN entry on the COTS 
device into which the PAN is entered. 


1D-5.4.a The tester must confirm through examination 
and observation that mechanisms to detect application 
overlays exist, and that it triggers the cancellation of any 
manual PAN entry currently in progress. 


Guidance 


It is common in many COTS OS for the OS-provided 
data entry functions to store data entered so that it can 
build a dictionary of commonly used terms, for the 
purposes of enhancing speli-check functions. In 
addition, some OSs allow for the replacemenit of the OS 
provided data entry functions with third party 
applications that may provide similar functions or 
perform other operations with data that is entered. 


It is important that account data entry functions secure 
against the exposure of the sensitive assets entered 
through these types of systems. 


To prevent oversight of the account data during entry, 
no more than one digit may be displayed at any time. 
Common implementations may display the more 
recently entered digit, with all other digits obfuscated 
using a generic symbol such as an asterisk. 


Capture of the account data through optical means, 
such as by taking a photograph of the payment card, 
can expose additional data not used during the 
transaction. 


Common malware attacks are known to overlay 
information on top of legitimate applications to obtain 
input data from the user. The MPoC SDK needs to be 
able to detect whether another application is overlaying 
the MPoC SDK and stop any transaction in progress. 
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Module 1E: PIN Entry on COTS Device 


This Module covers COTS-native PIN entry, even if the capability can be disabled at run-time with configuration options. If the MPoC SDK 
does not support PIN entry (or any other situation where the PIN may be exposed) on the COTS devices, this Module is not in scope. It is 
possible that the numeric value of the PIN is not captured by the MPoC SDK directly; instead, some interim value may be collected, such as 
touch locations or different numeric values, which must be reconstructed into the PIN at a later time by the MPoC SDK. These interim values 
must also meet all reguiremenis of this Section in respect to protections prior to the construction of the encrypted PIN block. In all cases, 
values related to the customer PIN, including individual digits, touch locations, or numeric values that can be mapped back to PIN values, 
must never leave the MPoC SDK until formed into a fully encrypted ISO format 4 PIN block. 


TE-1 COTS-native PIN Eniry 


This Section covers the entry of cardholder PINs on the COTS device. When the PIN is entered on the COTS device, regardless of 
whether the PIN entry mechanisms are backed by hardware (e.g., TEE), the MPoC SDK is reguired to comply with this Section. 


Security Reguirements 


| Test Reguiremenis 


| Guidance 


Objective: Cardholder PINs are protected as they are entered and processed on the COTS device. 


I 
1E-1.1 Documentation must exist that 
describes the secure capture and 
processing of the cardholder PIN. 


1E-1.1.a The tester must confirm through 
examination that the information provided contains, 
but is not limited to: 


» HowthePiN is protected during entry and prior 
to encryption. 


» HowthePiN is encrypted. 


» (The security mechanisms implemented to 
prevenit the extraction of the PIN at run-time. 


» (o Side-channel prevention mechanisms. 


» The iypesof PiN-verification method(s) 
supported (offline, online, or both). 


An MPoC SDK that accepts account data entry, including 
PINs, on COTS devices has to provide a path for these 
sensitive assets from the hardware of the COTS device, 
through the OS and drivers, to the MPoC SDK itselr. 


Documentation is reguired to demonstrate an 
understanding and consideration for the entire path taken 
by this data, not just how the data is received and 
processed within the MPoC SDK. For example, 
protections need to consider how to prevent 
determination of PINs through OS-level features such as 
screen recording or logging of touch inputs. 

The PIN needs to be protected against extraction using 
side-channels analysis (e.g., using the accelerometers 
and gyroscopes to obtain the coordinates of user touch 
evenis and correlate such touch events to individual PIN 
digits). 
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Security Reguiremenis 


1E-1.2 PIN eniry is supported only for 
chip-based transactions. 


Test Reguiremenis 


1E-1.2.a The tester must confirm through 
examination and observation that PIN entry is 
supported only for transactions with chip-based 
cards. 


Guidance 


Magnetic stripe cards do not provide the same security 
features present in chip-based cards and can be easily 
“cloned” or copied. An MPoC SDK that provides for the 
capture of both PIN and magnetic stripe track data for the 
same transaction are not permitted. This is true even if 
the track data is sent to the COTS device encrypted, from 
an attached SCRP or Non-PTS approved MSR because 
the data may be captured through a skimmer on the 
peripheral reader device itself. 


1E-1.3 The MPoC SDK must not leak 
complete or partial PIN digits. The MPoC 
SDK must protect against side channels 
that use sensors present in ihhe COTS 
device (e.g., accelerometers and 
gyroscopes) and screen capture. 


1E-1.3.a The tester must confirm through 
examination that: 


» Thethreatof extracting the PIN using the COTS 
device sensors was considered. 


» Kach sensor has arationale on why they do not 
present a risk for side channel extraction of the 
PIN. 


» (o Measures were implemented to preveni the 
leakage of the PIN using the sensors that 
present a risk. 


1E-1.3.b The tester must confirm through 
examination, observation, and testing the correct 
implementation of the measures that mitigates the 
extraction of the PIN through side channels. 


Some COTS device sensors can be used at the time of 
PIN entry to extract the PIN that is being entered by the 
cardholder. Furthermore, a COTS device output (e.g., 
distinctive sounds per key or change in the key digit on 
screen when pressed) can be used to extract the PIN 
from the COTS device using screenshots or recordings. 
Therefore, the MPoC SDK needs to ensure that the 
implementation accommodates for these issues and 
ensures that the method of PIN entry does not leak PIN 
digits through potential side channels. 


i 1E-1.4 The MPoC SDK must protect the 
PIN digits during entry. 


1E-1.4.a The tester must confirm through 
examination and observation that: 


» Thereisnofeedback that could be usedto 
identify the PIN digits. 


» İtis not possible to take screenshots or 
recordings of he MPoC SDK during PIN entry 
on the COTS device into which the PIN is 
entered. 


Some COTS device sensors can be used at the time of 
PIN entry to extract the PIN that is being entered by the 
cardholder. Furthermore, a COTS device output (e.g., 
change in the key digit on screen when pressed) can be 
used to extract the PIN from the COTS device using 
screenshots or recordings. 


Therefore, the MPoC SDK needs to ensure that the 
implementation accommodates for these issues and 
ensures that the method of PIN entry does not leak PIN 
digits through potential side channels. 
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Security Reguiremenis Test Reguiremenis Guidance 
1E-1.5 The PIN must be encrypted into an | 1E-1.5.a The tester must confirm through Methods that capture and encrypt the PIN in ways not 
ISO format 4-PIN block as soon asit is examination and observation that: compliant to IS09564 can result in unforeseen risk being 
captured. The PIN is encryoted into an ISO format 4-PIN introduced into the PIN-processing system. ISO 9564 
- block upon ii in all cases prior to Format 4 uses AES and encapsulates the PIN and PAN 
transmission outside of the boundary of the into the PIN block using separate encryption processes. 
MPoC SDK. This separation of the encryption processes within an ISO 


i format 4-PIN block allows for the PIN and PAN to be 
Ifth hic k h i i i 
ü Ne managed as separate items during the formatting of the 
ömirenmient ol tie COTG device. tia.PİN biöek PIN block (on the COTS device). Maintaining separation 
i i i ; i between the PIN and PAN can help increase the overall 
b EMEN SİM Mİ Ke pere ane le security of the MPoC Solution. However, separation of the 
PIN and PAN is not a reguirement. 


Only complete and encrypted ISO format 4 PIN blocks 
may be transmitted from the COTS device. 


A tokenized PAN, cryptographically bound to the actual 
funding PAN, may be used with these formats to allow for 
more complete dislocation of the PIN and PAN within the 
COTS device. Use of a PAN token is not reguired. 


Use of a PIN-encryption key that is unigue per transaction 
ensures that any compromise of a specific PIN entry 
event cannot be used to compromise previous PINs 
processed by that system. 


Only the entity that is intended to decrypt the PIN is 
permitted to have access to the decryption key. If a PCI 
PTS SCRP is used for PIN translation, only the PCI PTS 
SCRP is permitted to decrypt a PIN after encryption by 
the MPoC SDK. If no PCI PTS SCRP is used, only the 
processing backend is permitted to decrypt the PIN. 
PINs may be translated from ISO format 4 by a PCI PTS 


SCRP or by back-end systems, for onward processing as 
reguired. 
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Security Reguiremenis 


1E-1.6 Attestation functions detecting 
indications of potential compromise must 
be executed prior to each PIN eniry 
process. 


Test Reguiremenis 


1E-1.6.a The tester must confirm through 
examination and observation that attestation İs 
performed prior to each PIN entry. 


1E-1.6.b The tester must confirm through 
examination and observation that attestation and 
monitoring (A&M) validation is performed on the 
COTS device immediately prior to PIN entry. 


Guidance 


PIN entry is permitted only when the MPoC SDK is 
running in a secure state. It is important that these 
attestation functions be performed before the cardholder 
is prompted to enter PIN data. 


The MPoC SDK may have multiple levels of attestation 
and is reguired to have some level that is always active. 
Due to power and processing constraints, it may not be 
possible to have all attestation functions always active, 
and so execution of more complete attestation prior to 
PIN entry is reguired. 


Validation of attestation data is expected to be performed 
online for any online PIN entry process. 


1E-1.7 The MPoC SDK must detect when 
another application overlays the MPoC 
SDK during PIN capture. In case of 
positive detection, the MPoC SDK must 
cancel any PIN entry currenily in 
progress. 


1E-1.7.a The tester must confirm through 
examination and observation that mechanisms to 
detect application overlays exist, and that it triggers 
ihe cancellation of any PIN entry currentiy in 
progress. 


Common malware attacks are known to overlay 
information on top of legitimate applications to obtain 
input data from the user. The MPoC SDK needs to be 
able to detect whether another application is overlaying 
the MPoC SDK and stop any transaction in progress. 


1E-1.8 PIN-related data (PIN, PIN related 
values such as touch locations, PIN block, 
PIN key) must not be stored on the COTS 
device-persistent storage and must be 
erased once no longer reguired. 


1E-1.8.a The tester must confirm through 
examination and observation that PIN-related data 
is not stored on persistent storage. 


Cleartext PINs, encrypted PIN blocks, and PIN-encryption 
keys need to be cleared from the system as soon as they 
are no longer reguired. 


For both cleartext PINs and the PIN encryption key, this 
means once the encrypted PIN block is produced, these 
values are reguired to be securely erased. 


An MPoC SDK may perform the two encryptions reguired 
for an İSO format 4-PIN block as separate parts of the 
transaction, enabling encryption of the PIN as soon as 
possible and prior to the inclusion of the PAN or PAN 
token into the PIN block. 


The encrypted PIN block needs to be erased once the 
PIN block has been transmitted from the COTS device. 


i 1E-1.9 Offline PIN verification is 
supported only through the use of a PCI 
PTS SCRP. 


1E-1.9.a The tester must confirm through 
examination and observation that offline PIN 
verification is not allowed for transactions where the 
card has not been accepted through a PCI PTS 
SCRP. 


Offline PINs may be seni to the paymeni card in the clear, 
and therefore may be transmitted only when the card is 
presented into a tamper-responsive device, such as a PCI 
PTS SCRP. 
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Module 1F: Offline Payment Transactions 


This Module is applicable to MPoC Software that supports offline transactions, even if the capability can be disabled at run-time with 
configuration options. Offline transactions covered by this Module are offline EMV transactions (where the transaction authorization is 
completely offline) and store-and-forward transactions (where the terminal approves the transaction, but the authorization is performed online 
after connectivity is regained). 


Depending on the type of transaction, different types of data may need to be stored on the COTS device for eventual transaction authorization. 
İypes of data that may need to be stored and protected during an offline transaction includes account data and transaction results 
(cryptograms). 


Offline PIN verification (with a contact chip card presented through a PCI PTS SCRP) may be used in either online or offline approval 
processes. 


Assets stored for offline transactions must be protected according to their security needs. This Module covers additional security reguiremenis 
that are needed to provide protection to these assets when stored on the COTS device. The protection of assets during the processing of a 
payment is covered by separate Modules. 


Support for offline payment processing is not a reguired feature of an MPoC Solution and may not be possible in some payment solutions due 
to local or payment brand specific rules. 
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1F-1 Offline Paymeni Transactions 


This Section covers the reguiremenis for securing the processing and storage of data reguired as part of offline paymeni transactions. 


Security Reguiremenits 


| Test Reguiremenis 


Objective: Offline transaction results and account data are protected. 


| Guidance 


1F-1.1 Stored assets, such as account 
data and transaction results, needed to 
process offline Payment transactions 
must be encrypted in such a way that the 
cleartext values cannot be recovered on 
ihe COTS device after encryption. 


1F-1.1.a The tester must confirm through 
examination, observation, and testing that any 
assets, such as account data and transaction 
results, stored for offline transactions cannot be 
decrypted or recovered on the COTS device after 
encryption. 


To prevenit the recovery of cleartext sensitive assets, 
such data needs to be stored so that it is not recoverable 
on the COTS device. 


The reguirement is reguired to be enforced 
cryptographically through the use of keys that are 
securely removed from the COTS device immediately 
after encryption or using an approved asymmetric 
cryptography algorithm as described in Appendix C: 
Minimum and Eguivalent Key Sizes and Strengihs for 
Approved Algorithms. 


If symmetric cryptography is used, the COTS device 
cannot maintain sufficient information to recreate previous 
encryption keys after their removal. An example of 
symmetric cryptographic methods meeting this 
reguirement would be use of a unigue key per transaction 
key managemeni, with each transaction key erased upon 
the completion of that transaction. 

In such an example, it is reguired that reconstruction of 
ihe encryption keys is not possible, except in the back- 
end system. 
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Security Reguiremenis Test Reguiremenis Guidance 

1F-1.2 The MPoC Software must be able | 1F-1.2.a The tester must confirm through Offline transactions are communicated to the payment 

to deteci the deletion or modification of examination and observation that the MPoC backend as reguired. Prior to transmission, there is an 

offline transaction data. Software is able to detect the deletion or opportunity window to delete or modify transaction data. 
modification of offline transaction data. This may preveni the transaction from being 

acknowledged by the payment backend, alter the amount 

1F-1.2.b The tester must perform testing on the or parties involved in the transaction, or change the 
MPoC Software by performing offline transactions, outcome of transaction processing decisions. 


deleting and modiiying transaction data irom ihe Detection of the deletion may occur by the MPoC SDK 
COTS device, and verifying that: directiy, or by some other (backend) aspect of the MPoC 
» The MPoC Software is ableto detect that the Software. 
executed transactions were deleted or modified. Attempts to attack offline payment processing by deleting 
» o Further transaction processing is prohibited until | the MPoC Software from the COTS device is covered by 
the incident is reported to the A&M backendfor | a different reguirement. 


analysis. 

1F-1.3 The offline Payment transaction 1F-1.3.a The tester must confirm through Data that may be stored as part of an offline transaction 

data must be deleted once it has been examination and observation that any offline may include the PAN, transaction amount, and 

transmitted to the payment backend. transaction data is deleted once it has been transaction cryptograms obtained from the cardholder 

transmitted to the back-end system. paymeni instrumenit. 
To reduce the risk posed by the storage of that data, 
transaction data needs to be deleted after it is no longer 
reguired. However, deletion is to be delayed until after 
transmission of the data to process the transaction, to 
prevent attacks that may attempi to “force” the deletion of 
data by disabling communications. 
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Security Reguiremenis Test Reguiremenis Guidance 
1F-1.4 Payment transactions can only be | 1F-1.4.a The tester must confirm through Attackers may attempt to exploit offline processing to 
accepted in offline mode for a maximum examination and observation that any further process multiple transactions that would otherwise be 
period of 48 hours. transaction processing İs prevented when the MPoC | rejected if processed online. To reduce this risk, offline 
Software has been operating in offline mode for processing systems need to preveni further processing if 
more than 48 hours. they are prevented from connecting to the back-end 
system. 


The back-end paymeni-processing systems may be 
different to the back-end A&M processing systems. MPoC 
Software implementing offline payment processing need 
to achieve connectivity to the A&M backend at least every 
24 hours. 


The A&M connectivity reguiremeni is different from this 
reguiremeni and tested separately. This reguirement is to 
halt payment processing once offline payment processing 
has been enabled for more than 48 hours. 


1F-1.5 Data stored for offline transaction 1F-1.5.a The tester must confirm through Although offline data is reguired to be protected 
processing must not be accessible to examination and observation that the offline data is cryptographically, it also needs to be isolated from other 
other applications. stored at a location not accessible to other applications as part of a defense-in-depth approach to 
applications. protecting that data. 
1F-1.6 Transactions currently underway 1F-1.6.a The tester must confirm through Online transactions may allow for operations that are not 
during a transition to offline processing examination and observation that the transition to permitted as part of an offline transaction — e.g., online 
are either failed in a secure manner or offline processing is managed securely, so that any | PIN capture is not permitted for offline payment 
managed in compliance with the transaction currently in process is either failed in a processing. İn cases where a transaction is currently 
reguiremenis of this Section. secure manner or is compliant to the reguiremenits underway during the transition to offline processing, it is 
of this Section. important that the transactions is either failed in a secure 


manner, or the processing of that transaction is compliant 
to the reguiremenis of this Section. 
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1F-2 Offline Monitoring 


Solutions providing offline payment processing must implement attestation and monitoring functions on the COTS device that are able to 
operate securely without connectivity with the A&M back-end component. Although these reguiremenits exist to support MPoC Solution 
where a system is disconnected from both the paymeni processing back-end systems, and the A&M back-end systems, it is noted that 
offline payment processing is a separate consideration and does not necessarily reguire that the back-end A&M systems are 
unavailable. 


Security Reguiremenis | Test Reguiremenis | Guidance 


Objective: The MPoC SDK can securely operate and attest its environment during periods where connection to the A&M backend is lost. 


1F-2.1 The initiation of the offline mode 1F-2.1.a The tester must confirm through The MPoC SDK cannot start in offline mode from a reboot 
must not be available immediately after examination and observation that it is not possible state without first contacting the server. This helps 

COTS device reboot. The MPoC SDK to perform offline transactions if the A&M and mitigate attacks when the timer is manipulated by 

must work offline only after being paymeni-processing servers have not been rebooting the COTS device or when the firmware is 
connected to the A&M backend. contacted after a reboot of the COTS device. modified since the last contact with the A&M server. 


Validation of the local time as indicated by the COTS 
device during reconnections may be used as part of the 
A&M data. The ability to correctly indicate local time is 
important for the secure operation of the MPoC SDK. 


1F-2.2 The MPoC SDK A&M component 1F-2.2.a The tester must confirm through It is expected that the MPoC SDK acts upon the results of 
must support a separate attestation policy | examination that the MPoC SDK A&M component the offline executed security checks to prevent fraud. The 
for offline operation. supports a separate attestation policy for offline degree of certainty of the security checks needs to be 


operation. The MPoC SDK A&M component must defined in the A&M offline mode policy. 
support the following actions: 


» o Confidentiality protected logs of any checks that 
have a high chance of false positive results. 


» İmpedethe ability totransaci until the A&M 
backend is contacted for checks with high 
confidence of compromise (e.g., detection of 
specific hacking tools). 


» Local checksmustinclude at leastroot 
detection, instrumentation detection, data- 
tampering checks, and local OS attestation if 
supported by the COTS platform. 
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Security Reguiremenis 


1F-2.3 The A&M backend must 
implement controls to mitigate attacks 
attempting to delete the MPoC SDK, or 
MPocC Application, during offline 
processing. 


Test Reguiremenis 


1F-2.3.a The tester must confirm through 
examination and observation that the A&M backend 
implements controls to mitigate attacks attempting 
to delete the MPoC SDK, or MPoC Application, 
during offline processing. 


Guidance 


An attacker may attempt to delete the MPoC SDK, or 
MPoC Application, from a COTS device during offline 
processing, so that any stored transactions are lost. 


Although this cannot be prevented, the A&M backend is 


reguired to track offline use in attempis to identify such 
abuse. For example, a system may flag merchanits or 
COTS device instances where offline processing is 
enabled and the next appearance of that merchant or 
system is a new installation. 


1F-2.4 The MPoC SDK must disable 
payment acceptance after 24 hours 
without receiving a response from the 
A&M back-end allowing for the continued 
processing of transactions. 


1F-2.4.a The tester must confirm through 
examination and observation that the MPoC SDK 
must disable processing after 24 hours without a 
response from the A&M back-end allowing for the 
continued processing of transactions. 


It is not a reguiremenit that the MPoC SDK supports 
offline payment processing; however, where this is 


supported, communications with the A&M backend may 


be interrupted during this time. In such cases, it İS 
acceptable for the disablement of online payment 
acceptance to be delayed for up to 24 hours. 


1F-2.5 The results of the A&M security 
checks that are not dependent on the 
backend must be resistant to tampering to 
an attack rating of 25 points using the 
attack-costing framework in Appendix B. 
The verification/assessment of these 
security check results cannot be delayed 
until connection to the A&M backend is 
reestablished. 


1F-2.5.a The tester must perform testing on the 
MPoC SDK by triggering security checks in the 
MPoC SDK while in offline mode and verifying that 
they are active in offline mode, and that any 
response or reaction reguired by the attestation 
policy is enacted. 


1F-2.5.b The tester must perform testing on the 
MPoC SDK by attempting to extract card data and 
PIN data from the MPoC SDK when using the offline 
A&M configuration. 


1F-2.5.c The tester must provide a costing of this 
attack based on the method outlined in Appendix B. 
Attack Costing Framework. This reguirement is 
passed if the most feasible attack cannot be costed 
for less than 25 points. 


Security checks that do not depend on a back-end system 


to obtain aresult (e.g., root detection, anti-tampering, 
etc.) need to be assessed locally while in offline mode. 
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Module 1G: MPoC Software Security Guidance 


MPoC Software includes the COTS-based MPoC SDK, which includes both payment and attestation functionality, and the back-end 
attestation and monitoring software. 


This Module applies in all cases to MPoC Software that is to be separately listed as an MPoC Product. This Module additionally applies to 
solutions that separate the MPoC functionality from other parts of an MPoC Application, including those where the MPoC Solution Provider 
and the MPoC Application vendor are the same organization. 


Monolithic MPoC Solutions are exempit from this Module as they do not use an MPoC SDK, and do not outsource the operation of their 
Attestation and Monitoring services. 
1G-1 Security Guidance 


The security guidance of a component is a document that defines the purpose and usage of the component, the security claims of the 


component, the component dependencies, and contains the reguired information to integrate and use the component in a secure 


manner. 


Security Reguiremenis 


Test Reguiremenis 


Guidance 


Objective: The MPoC Software is provided with documentation that allows for secure integration and use within a complete MPoC Solution. 


1G-1.1 The MPoC Software must be 
provided with a security guildance 
document that describes how the MPoC 
SDK can be integrated with an MPoC 
Application. 


1G-1.1.a The tester must confirm through 
examination that there is a security guidance 


document that is provided with the MPoC Software. 


This document must be made visible and readily 
accessible to all entities integrating the MPoC 
Software into their own systems or solutions. 


An MPoC Software needs to be integrated as expected 
by the MPoC Solution provider and the assessment 
laboratory to ensure that the validated security features 
are correctly implemented. 


The MPocC Solution provider is reguired to provide 
documentation about how this integration is achieved, 
and the laboratory needs to validate that this conforms to 
their expectations and testing setup. 


1G-1.2 The MPoC Software security 
guidance document must define the type 
of MPoC SDK that is implemented. 


1G-1.2.a The tester must determine through 
examination, observation, and testing that the 
MPoC SDK provided as part of the MPoC Software 
is either an Isolating SDK, or a non-Isolating SDK. 
The tester may refer to the results from previous 
test items in making this determination. 


1G-1.2.b The tester must confirm through 
examination that the MPoC Software security 
guidance document correctiy details the type of 
MPoC SDK implemented by the MPoC Software. 


An MPoC SDK may take one of two types. The first type 
is an Isolating MPoC SDK, which prevents the MPoC 
Application from accessing the memory or sensitive 
assets of the MPoC SDK. Any MPoC SDK that does not 
meet this reguiremeni to isolate and protect its own 
memory and sensitive assets İs considered a non- 
Isolating SDK. 
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Security Reguiremenis 


1G-1.3 The MPoC Software must be 
provided with a security guidance 
document that describes how the MPoC 
Software is to be operated by an 
Attestation and Monitoring Service 
provider. 


Test Reguiremenis 


1Ğ-1.3.a The tester must confirm through 
examination that there is a security guidance 
document that is provided with the MPoC Software. 
This document must be made visible and readily 
accessible to all entities integrating the MPoC 
Software into their own systems or solutions. 


Guidance 


An MPoC Software needs to be integrated as expected 
by the MPoC Solution provider and the assessment 
laboratory to ensure that the validated security features 
are correctly implemented. 


The MPocC Solution provider is reguired to provide 
documentation about how this integration is achieved, 


and the laboratory needs to validate that this conforms to 
their expectations and testing setup. 


Clear documentation over the boundaries of the MPoC 
SDK is needed to scope the functionality of the MPoC 
Software properly and assess the evaluated componenis. 


The boundary has to include any hardware (e.g., PCI PTS 
SCRP, SE) that performs, or software that implemenis, 
any of the MPoC SDK-designated security functionalities. 


The MPoC SDK boundary needs to define how account 
data is input to the MPoC SDK, and how A&M and control 
signals pass between the MPoC SDK and other 
componenis of the Solution. 


Although interfaces such as the COTS-native NFC reader 
or touch screen are not part of the MPoC SDK boundary, 
it is reguired that they be considered part of any account 
data input methods into the MPoC SDK. 


1G-1.4 The MPoC Software security 
guidance document must define an 
explicit MPoC SDK boundary. 


1G-1.4.a The tester must confirm through 
examination that the security guildance document 
includes an explicit MPoC SDK boundary. 


1G-1.4.b The tester must confirm through 
examination that the MPoC SDK boundary, as 
defined, aligns with their understanding of the MPoC 
Software and includes details about how all account 
data and A&M data are input or output from that 
boundary. 


1G-1.5 The MPoC Software security 
guidance document must provide details 
about how the MPoC Software code and 
configuration settings can be updated 
securely. 


1Ğ-1.5.a The tester must confirm through 
examination that the reguired information is included 
and that it matches the understanding of the tester 
of the MPoC Solution. 


Clear documentation about how updates to the MPoC 
Software and its configuration can be made is vital. 
Because the MPoC Software is designed for integration 


into other components of an MPoC Solution, updates may 


reguire specific processes or prereguisites. When an 


MPoC Software makes assumptions about the source or 
protections provided to updates, this needs to be clearly 
detailed in the security guidance documentation. 


Updates covered by this guidance includes data such as 
configuration for EMV kernels. 
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Security Reguiremenis 


1G-1.6 The MPoC Software security 
guidance document must provide details 
about how any software-protected 
cryptography implementations impact the 
freguency of MPoC Application updates. 


Test Reguiremenis 


1Ğ-1.6.a The tester must confirm through 
examination that the MPoC Software security 
guidance documentation indicates how often any 
software-protected cryptography implementations 
must be updated. This time period must be no more 
than the minimum period included as part of the 
testing of the software-protected cryptography. 


Guidance 


An important part of the security posture of any software- 
protected cryptography is the ability to provide regular 
updates. Any implementation of an MPoC SDK using a 
software-protected cryptography needs to ensure that it 
complies with this update process, which starts with 
providing this information in the MPoC Software security 
guidance documentation. 


1G-1.7 The MPoC Software security 
guidance document must list all assets 
that cross the boundary of the MPoC SDK 
and the expected protection that the 
integrator of the MPoC SDK must provide 
to these assets. 


1G-1.7.a The tester must confirm through 
examination that the reguired information is included 
and that it matches the understanding of the tester 
of the MPoC Solution. 


It is important that the expectations of the MPoC SDK 
regarding protecting assets are understood for the 
integrator and the laboratory that evaluates the integration 
of the MPoC SDK. 


An MPoC SDK may take the form of a non-Isolating SDK, 
or an İsolating SDK. An Isolating SDK must ensure that 
all sensitive assets — such as cryptographic keys and 
account data — are protected according to their asset type 
when passed outside of the boundary of the MPoC SDK. 


A non-Isolated MPoC SDK may provide the MPoC 
Application with access to some assets, such as the PAN 
to be used for the purpose of loyalty transactions or to 
support non-paymeni card capture. If such access İS 
permitted, this must be detailed in the guidance 
documentation. 


Even for an Isolating SDK. not all assets that cross the 
boundary between the MPoC SDK and the MPoC 
Application reguire protection. Assets that are inherently 
protected by the MPoC SDK, such as through encryption 
prior to crossing the boundary to the MPoC Application, 
do not reguire further protection. However, such assets 
and the protections applied must still be identified. 


1G-1.8 The MPoC Software security 
guidance document must contain detailed 
guidance for secure integration that 
includes configuration flags, usage of 
APls, and expected security mechanisms 
to be applied. 


1G-1.8.a The tester must confirm through 
examination that the security guildance: 


» Maichesthe testers understanding of the MPoC 
Solution. 


»* İs sufficientfor secure integration of the MPoC 
SDK (i.e., it details how to integrate the MPoC 
SDK in a way that would enable the integrating 
MPoC Application to meet the relevant 
reguiremenis of this standard). 


The integrator is reguired to be aware of how to configure 
the MPoC Software properly for deployment and what 
security mechanisms are expected to be included during 
ihe development. 
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Security Reguiremenis 


1G-1.9 The MPoC Software security 
guidance document must indicate which 
COTS Platforms (including platform 
versions such as OS, TEE, and SE) are 
supported. 


Test Reguiremenis 


1Ğ-1.9.a The tester must confirm through 
examination that the reguired information is included 
and that it matches the understanding of the tester 
of the MPoC Solution. 


Guidance 


The MPoC SDK is permitted to be used only on platforms 
that have been validated to provide the necessary 
security and functional aspects reguired. The integrator 
needs to limit the use of the MPoC SDK only to platforms 
where the MPoC SDK can be used securely. 


Sufficient granularity should be provided so that an 
integrator of the MPoC Software Product is able to know 
which platforms to target for their MPoC Application. This 
information must be kept current as changes in the 
supported COTS platforms occur over time. 


1G-1.10 If the attestation needs an 
interaction from the MPoC Application, 
the MPoC Software security guidance 
document must define the scope, 
dependencies, and actors of an 
attestation policy that is used by the 
MPocC Solution. 


1G-1.11 The MPoC Software security 
guidance document must provide details 
on the reguired key management 
processes and operations. 


1G-1.10.a The tester must confirm through 
examination that the reguired information is included 
and that it matches the understanding of the tester 
of the MPoC Solution. 


1G-1.11.a The tester must confirm through 
examination that the MPoC Software security 
guidance provides sufficient details on how to 
operate the key management reguired by the MPoC 
Software. 


1G-1.11.b The tester must confirm through 
examination that the guidance clearly outlines who 
is responsible for the management of each key 
management aspeci of the MPoC Software. 


MPoC SDK functionality may need interactions with the 
MPoC Application that are not functional, but which are 
needed for security. These interactions are reguired to be 
documented properly such that the integrator knows how 
to use the MPoC SDK properiy. 


Interactions include specific API calls, configuration for 
periodicity and status, or other types of triggers. 


The MPoC Software is validated as implementing certain 
key management and encryption operations. However, all 
key management reguires support from back-end 
systems, and it is reguired that the operational aspects of 
the key management are clearly defined in the MPoC 
Software security guidance document. Where different 
parties may be responsible for different aspecis of key 
management, this is to be indicated in the document. 
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Domain 2: MPoC Application Integration 


The security reguiremenis in this Domain apply to MPoC Applications that integrate, or interface to, a listed MPoC SDK or are developed as 
part of a monolithic solution. MPoC Applications may be developed by an MPoC Software vendor, an MPoC Solution provider, or by another 
party. However, the Entity responsible for the listing of an MPoC Product is also responsible for managing the assessment and listing of any 
MPoC Applications associated with that MPoC Product. 


An MPoC Solution may have more than one MPoC Application listed as part of that MPoC Solution listing. 


Further details on the different types of MPoC Applications can be found in Section: MPoC SDKs and MPoC Applications. Details on the 
applicability of the various Domains and reguiremenis of this standard can be found in Section: MPoC Domain and Section Applicability. 
Details on the process and reguirements for MPo€ listings can be found in the MPoC Program Guide. 


Module 2A: MPoC Software Integration 


This Module covers the integration of one or more MPoC SDKSs, which are part of listed MPoC Software Products, into an MPoC Application. 
Any one MPoC Application is not permitted to integrate more than two MPoC SDKs. An MPoC Application that integrates both an Isolating and 
non-İsolating MPoC SDK, is assessed against reguirement as they apply to the integration of a non-Isolating MPoC SDK. 


Note: This Module is applicable for MPoC Applications that integrate an MPoC SDK, regardless of the type of MPoC SDK used (Isolating SDK 
or non-Isolating SDK). Monolithic MPoC Applications are exempt from this Module. 


2A-1 Secure MPoC SDK Integration and Usage 


An MPoC SDK, when used, must be securely and correctiy integrated into an overall MPoC Solution that includes the integration into 
the MPoC Application distributed and used by merchants. This integration must follow the guidance provided by the MPoC Solution 
provider, as well as ensuring reguiremenis of this standard are met for the integrated system. 


Security Reguiremenis 


| Test Reguiremenis 


Guidance 


Objective: When an MPoC SDK is used, it must be integrated into the overall MPoC Solution securely and correctly. 


“2A-1.1 When an MPoC SDK is used, the 
MPoC SDK must be part of alisted MPoC 
Software product. 


2A-1.1.a The tester must confirm through 
examination that the version of the MPoC SDK used 
by the MPoC Application vendor is listed on the PCI 
website as an MPoC Software product. 


MPocC Solutions, including the MPoC Applications are 
reguired to be evaluated in their entirety before approval. 
When an MPoC SDK is relied upon for some aspeci of 
compliance, that MPoC SDK needs to have been 
previously assessed and listed as part of an MPoC 
Software product. 
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Security Reguiremenis 


2A-1.2 The MPoC SDK must be 
integrated with the MPoC Application and 
solution in accordance with the MPoC 
Software security guidance. 


Test Reguiremenis 


2A-1.2.a The tester must confirm through 
examination and observation that the MPoC 
Application vendor has integrated the MPoC SDK in 
accordance with the MPoC Software security 
guidance. 


Guidance 


An MPoC SDK provides various security services and 
functions to assist with the overall compliance of the 
MPoC Solution. To ensure correct and secure operation 
the MPoC SDK needs to be integrated and used as 
intended. 


An MPoC SDK may rely on the MPoC Application to 
provide a deployment configuration to be used securely. 
The MPoC Application vendor needs to follow the 
reguiremenis from the MPoC SDK security guidance 
(e.g., on the use of configuration flags, APls, and 
protection mechanisms to be applied to the final 
integrated MPoC Application). 


2A-1.3 The MPoC Application integrating 
the MPoC SDK must not bypass, 
circumveni, reimplement, or modify any of 
ihe security or operational features 
provided by the MPoC SDK. 


2A-1.3.a The tester must confirm through 
examination and observation that the MPoC 
Application integration did not modify or re- 
implement MPoC SDK features that are within the 
MPoC SDK boundary. 


An MPoC SDK is evaluated and approved based on the 
features it provides. Alteration or bypassing any of those 
features may impact the security of the MPoC SDK in 
unexpected ways. Therefore, any MPoC SDK needs to be 
used only as outlined in the provided security guidance 
documentation. 


For example, an MPoC Application that integrates an 
MPoC SDK that provides PIN entry cannot bypass this 
function to provide its own PIN entry or encryption 
methods. 


2A-1.4 The MPoC Application does not 
manage, process, or provide for the input 
of any sensitive assets, or the MPoC 
Application is assessed to the 
reguiremenis of Domain 1. 


2A-1.4.a The tester must confirm through 
examination and observation that the MPoC 
Application does not manage, process, or provide 
for the input of sensitive assets such as cardholder 
PINS, cryptographic keys, or account data. 


2A-1.4.b Where the MPoC Application is found to 
manage, process, or allow for the input of sensitive 
assets, the tester must confirm that the MPoC 
Application has been included in the scope of the 
Domain 1 assessmenit. 


The MPoC Application relies on the MPoC SDK to 
manage all sensitive assets such as cardholder PINs and 
account data. Where an MPoC Application manages, 
processes, or provides input to any sensitive assets, the 
MPoC Application is considered a monolithic MPoC 
Application for the purposes of assessmeni (and therefore 
is reguired to be assessed against Domain 1 of this 
standard). 


Assets that are encrypted by the MPoC Software (or by a 
system or entity external to the COTS device) using 
cryptographic methods and key management assessed 
under Domain 1 of this standard are considered suitabiy 
protected and not in scope of this reguiremenit. 
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Security Reguiremenis 


2A-1.5 Attestation functions provided by 
the MPoC Software must be securely and 
correctly integrated into the MPoC 
Application. 


Test Reguiremenis 


2A-1.5.a The tester must confirm through 
examination and observation that the MPoC 
Application vendor has integrated the MPoC 
Software A&M functions as reguired in the MPoC 
Software security guidance document. 


2A-1.5.b The tester must test the A&M system by 
blocking the attestation from happening, either by 
tampering with the MPoC Application or the 
communication with the A&M backend and attempt 
to perform paymenits, and verify that it is mandatory 
to perform attestation as reguired by the A&M 
policy. 


Guidance 


The MPoC Application is the method by which the MPoC 
SDK functions are delivered to the merchant. 
Compromise of an MPoC Application may prevenit or alter 
the secure operation of the MPoC Solution, and so the 
security of the MPoC Application must be evaluated as 
part of the attestation and monitoring process. 


Attestation functions provided by the MPoC SDK may 
reguire specific integration steps or interactions with the 
MPoC Application. For example, specific triggers or data 
points to support the secure operation of the attestation 
functions may be reguired within the MPoC Application. 


These interactions are reguired to have been documented 
properiy as part of the MPoC SDK validation. The process 
that this documentation outlines needs to be followed to 
ensure that the MPoC SDK provides the security features 
that are expected of it. 


Attestation needs to be an integral part of the MPoC SDK 
and MPoC Application flows. This means that initiating 
transactions, without having performed and passed 
attestation, needs to be prevented. This control may be 
enforced in the paymeni-processing environment (e.g., by 
reguesting proof of successiul attestation). 


The paymeni-processing environment is reguired to be 
aware when attestation is due, and not process data 
unless attestation has happened. It is reguired that the 
MPoC Application becomes unable to transaci if 
communication between the MPoC Application and 
attestation API(s) is blocked. For offline use cases, this 
reguirement still applies. Tne MPoC Application needs to 
perform local attestation during offline periods and needs 
to ensure successful A&M connection and validation prior 
to any further paymeni processing when coming back 
online. 


2A-1.6 The MPoC Application does not 
integrate more than two MPoC SDKSs. 


2A-1.6.a The tester must confirm through 
examination and observation that the MPoC 
Application does not integrate more than two MPoC 
SDKS. 


Integration of multiple MPoC SDKSs is permitted, but 
increases the complexity and potential attack surface of 
the MPoC Application. To limit the risk posed by 
integration of multiple MPoC SDKSs, no more than two 
may be integrated into a single MPoC Application. 
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Security Reguiremenis Test Reguiremenis Guidance 

2A-1.7 The MPoC Application does not 2A-1.7.a The tester must confirm through During assessment to Domain 1, it is established that the 

implemenit, or allow for, the decryption of examination and observation that the MPoC MPoC SDK only outputs sensitive assets when that data 

encrypted sensitive assets output by the Application does not implement or allow for the is appropriately protected (e.g., through the use of 

MPoC SDK. decryption of sensitive assets encrypted by the encryption). It is important that the MPoC Application 

MPoC SDK. does not attempit to bypass this security, by implementing 

decryption functions to recover the cleartext sensitive 
assets. 

i 2A-1.8 The MPoC Application does not 2A-1.8.a Where more than one MPoC SDK is An MPocC Application may integrate up to two MPoC 
share assets between different MPoC integrated into an MPoC Application, the tester must | SDKs. However, in cases where this is done the MPoC 
SDKS. confirm through examination and observation that SDKs must continue to operate independently of each 

assets are not shared between the different MPoC other, even if this leads to differences in user experience. 
SDK$. Put another way, the existence or removal of one MPoC 


SDK should not impact the operation or security of 
another MPoC SDK integrated into a single MPoC 


Application. 
2A-1.9 The MPoC Application is assigned | 2A-1.9.a The tester must confirm through It is common for COTS Platforms to reguire that specific 
only the privileges reguired for its secure examination that the MPoC Application is assigned privileges are assigned to each application that executes 
operation. only the privileges it reguires for secure operation. on that platform. It is important that the MPoC Application 
is only assigned those privileges it reguires for secure 
operation. 


2A-1.10 The MPoC Application is either 2A-1.10.a If the tester is unable to confirm through Even though an MPoC Application may not be specificaliy 


unable to access any memory and examination and observation that the MPoC designed to access MPoC assets such as cardholder 
storage locations where MPoC assets Application is unable to access the memory and PINs, cryptographic keys, or account data, the 

may be processed or reside, or the storage locations used to process or store MPoC implementation of the MPoC SDK, or MPoC Application 
reguiremenis of Module 2B have been assets, all further reguiremenis in this Module must integrating the MPoC SDK, may allow for access to the 
met. be assessed. memory or storage areas that contain these assets. In 


ihese cases, compromise of the MPoC Application will 
result in exposure of these sensitive assets. 
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Module 2B: MPoC Application Security 


This Module covers all security mechanisms reguired of MPoC Applications that share memory with, or have access to the memory of, the 
MPoC SDK they are integrating. This Module will always apply to monolithic MPoC Applications, and MPoC Applications that integrate a non- 
Isolating MPoC SDK. MPoC Applications that integrate an Isolating MPoC SDK, but do so in a way that compromises the isolation provided by 
that SDK, must also be assessed to the reguiremenis of this Module. 


The MPoC Software security guidance, and MPoC Software listing, details if an MPoC SDK is an Isolating SDK or non-Isolating SDK. 


2B-1 MPoC Application Security 


MPoC Applications that may be able to access MPoC SDK assets must be developed in line with security best practices for COTS 


device applications. 


Security Reguiremenis 


| Test Reguiremenis 


| Guidance 


Objective: MPoC Applications that could have access to assets are developed in line with security best practice. 


 2B-1.1 All software in the MPoC 
Application must be either: 
»* (DevelopedbyaPcli SLC Oualified 
Software Vendor 
e (o Compily with all reguiremenits in 
Appendix D: Software Security 
Lifecycle Reguiremenis. 


2B-1.1.a When the software is developed by a PCI 
Secure SI C-approved software vendor, the tester 
must confirm through examination that the entity İs 
listed on the PCI website and is valid at the time of 
evaluation (i.e., the listing has not expired). 


A non-Isolating SDK has not been validated to provide 
sufficient protection to its assets. Compromise of an 
MPoC Application that integrates a non-Isolated SDK can 
therefore lead directly to the compromise of the MPoC 
SDK assets. 


Therefore, it is important that any MPoC Application that 


2B-1.1.b When the software is not developed by a 
PCI Secure SLC-approved software vendor, the 
tester must confirm through examination, 
observation, testing, and interview that the 
reguiremenis in Appendix D: Software Security 
Lifecycle Reguiremenis are met. 


integrates a non-İsolated SDK is created using secure 
software development best practices. This will help 
reduce the potential for vulnerabilities in the MPoC 
Application, increasing the security of the overall MPoC 
Solution. 
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Security Reguiremenis 


2B-1.2 The MPoC Application data and 
code must be protected against tampering 
(modification), including at runtime, to an 
attack rating of 25 points using the attack- 
costing framework in Appendix B. 
Protections must include controls to 
mitigate attempis to perform rollback on 
the MPoC Application or COTS OS. 


Test Reguiremenis 


2B-1.2.a The tester must confirm through testing 
that the modification (including application rollback) 
is detected by the MPoC Application and it is not 
possible to perform transactions. 

If the modification is detected, the tester must 
attempit to bypass (i.e., disable or remove) the 
tamper detection code. 


2B-1.2.b The tester must provide a costing of this 


attack based on the method outlined in Appendix B. 


Attack Costing Framework. This reguirement is 
passed if the most feasible attack cannot be costed 
for less than 25 points. 


Guidance 


The MPoC Application installable package needs to have 
its authenticity protected. This is normally a task that the 
MPoC Software cannot perform, as it has no visibility on 
the integration part of the MPoC Application. 


The MPoC Application binary code is reguired to be 
resistant against tampering. The MPoC Application is 
reguired to implement controls to prevent modification of 
tihe MPoC Application installed on the COTS device, 
including its configuration files, and binary code. 


The MPoC Solution needs to prevent older and possibiy 
vulnerable versions of the MPoC Application from 
running. The version allowed to be used is controlled by 
tihe MPoC A&M backend, and validation of this 
functionality is performed in Module 1C. 

A deprecated version is an older version not allowed to be 


operational in the field due to being too old or 
compromised. 
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Domain 3: 


Attestation and Monitoring 


These reguiremenis cover the operational aspecis of the A&M. If an A&M service provider wants to have its A&M Service listed independently 
from an MPoC Solution, the A&M service provider is responsible to ensure that the reguiremenis in this Domain are met. When an MPoC 
Solution provider is not using an A&M service provider, the MPoC Solution provider is responsible to ensure that the reguiremenis in this 


Domain are met. 


Module 3A: MPoC Software Security Guidance Compliance 


This Module covers the deployment and configuration of a certified attestation and monitoring software into the backend. 


Note: This Module is applicable for composite solutions only. 


34-1 Deployment and Configuration of Back-end Systems 


An MPoC Software product, when used, must be securely and correcily integrated into an overall MPoC Solution. This integration must 
follow the guidance provided by the MPoC Solution provider, as well as ensuring reguiremenits of this standard are met for the 


integrated system. 


Security Reguirements 


Test Reguiremenits 


Guidance 


Objective: MPoC Software back-end systems, when used, are securely and correcily deployed and configured. 


3A-1.1 When an MPoC Software product 
is used, the MPoC Software product must 
be listed on the PCI SSC website. 


3A-1.1.a The tester must confirm through 
examination and observation that the version of the 
MPoC Software used by the Attestation and 
Monitoring Service provider is PCI approved. 


MPoC Solutions need to be evaluated in their entirety 
before listing. When an MPoC Software is relied upon for 
some aspect of compliance, that MPoC Software needs 
to have been previously assessed and approved. 


3A-1.2 Back-end systems must be 
deployed and configured in accordance 
with the MPoC Software security 
guidance. 


3A-1.2.a The tester must confirm through 
examination and observation that the Attestation 
and Monitoring Service provider has deployed and 
configured the back-end system in accordance with 
MPoC Software security guidance. 


The MPoC Software back-end system provides various 
security services and functions to assist with the overall 
compliance of the MPoC Solution. To ensure correct and 
secure operation, back-end attestation system and back- 
end monitoring system need to be deployed and 
configured as intended. 


3A-1.3 The Attestation and Monitoring 
Service provider must not bypass, 
circumveni, re-implement, or modify any 
of the security or operational features 
provided by MPoC Software. 


3A-1.3.a The tester must confirm through 
examination and observation that the integration of 
tihe MPoC Software did not modify or re-implement 
MPoC Software features that are within the MPoC 
Software boundary. 


An MPocC Software is evaluated and approved based on 
ihe features that it provides. Alteration or bypassing of 
any of those features may impact the security of the 
MPoC Software and the MPoC Solution in unexpected 
ways. 
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Security Reguiremenis Test Reguiremenis Guidance 
3A-1.4 The Attestation and Monitoring 3A-1.4.a The tester must confirm through The MPoC Software may be developed by an entity 
Service provider must have process in examination that the back-end A&Ms supports different to that which deploys and operates the back-end 
place to detect when their back-end secure updates according to the MPoC Software attestation system and back-end monitoring system. Even 
systems reguire updates. security guidance document. where the same entity develops and operates the back- 
end systems, there may be separate teams or resources 
3A-1.4.b The tester must confirm through used for each. 
examination that the A&M service provider has a To ensure that back-end systems remain up to date, the 
process to deliver updates in a timely manner, and attestation monitoring service provider needs to have 
this process is in demonstrable use. processes in place to monitor published updates and 
releases. 


Although newly developed systems may not yet have a 
need to implement updates, the need to continually 
monitor for such need remains. It is also expected that 
any A&M service provider will need to implement updates 
freguently to maintain the currency and security posture 
of their systems, and therefore even newly developed 
systems will reguire updates within a short period of time. 
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Module 3B: Baseline 


This Module contains reguiremenis for the management of ihe COTS platform baseline. 


Note: This Module is applicable to all A&M service providers, and/or monolithic MPoC Solution providers. 


3B-1 COTS Platform Baseline and Vulnerability Management 


The COTS platform baseline represents the COTS platforms (including both the physical device and the operating systems used) that 
are considered to provide sufficient security and features to allow for the installation and execution of the MPoC Application for the 
purposes of accepting paymeni transactions. This baseline must be managed as new security flaws, as well as updated and more 
secure versions of GOTS platforms, are released. 


Security Reguiremenis | Test Reguiremenis | Guidance 


Objective: The defined COTS platform baseline is kept up to date with developmenis and changes to COTS platforms. 


3B-1.1 A COTS platform baseline must 3B-1.1.a The tester must confirm through The COTS platform baseline outlines the COTS platforms 
exİst. examination and observation that a COTS platform on which the MPoC Application may execute and accept 
baseline exists and is validated by the A&M. payment transactions. The establishment and 


maintenance of this baseline must include the minimum 
set of features reguired of the MPoC Software, both those 
outlined in this standard and those self-imposed by the 
MPoC Solution itself. 

The baseline may be instantiated in various ways and is 
expected to include use of both whitelist and specific 
block-list elements. For example, a baseline may include 
accommodation for COTS devices with a specific OS 
version, excepi for those COTS devices that also have 
certain undesirable features (such as NFC logging, or 
insecure OS modifications). 


The inclusion of any COTS device executing the MPoC 
Software must be validated by the A&M. 
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Security Reguiremenis 


3B-1.2 A procedure for managing the 
COTS platform baseline must exist and 
be demonstrably in use. 


Test Reguiremenis 


3B-1.2.a The tester must confirm through 
examination that the COTS platform baseline 
procedure exists. The tester must examine the 
procedure to verify that it contains at a minimum: 


» Roles and Responsibilities (e.g., who is allowed 
to update the COTS platform baseline). 


» The acceptance process and criteria for adding 
COTS platforms to the COTS platform baseline 
(see next reguiremeni). 


» How COTS platforms are added to the COTS 
platform baseline. 


» (How decisions are made to remove previously 
acceptable COTS platforms from the COTS 
platform baseline. This must include a reference 
to the vulnerability management process. 


» (How affected entities are informed of changes 
to the COTS platform baseline that will affect 
them. 


3B-1.2.b The tester must confirm through 
examination and observation that the COTS 
platform baseline includes: 


» TheCOTSplatform's that are supported. 
» (o Fach supportedCOTS platform provides ata 
minimum: 
— An enforcing mandatory access control 
framework. 


— Atrusted boot mechanism that 
validates the OS authenticity. 

— Validation of an application 
cryptographic signature upon 
installation of applications. 

—  İsolation of the interfaces and memory 
spaces used by different applications. 


Guidance 


The COTS platform baseline is not static and will change 
over time. Therefore, a procedure is reguired be in place 
to manage the existing baseline with respect to risks to 
the solution. 


There needs to be a clear process for accepting platforms 
into the COTS platform baseline that ensures the MPoC 
Application can execute and perform its functions as 
intended and in a secure manner. 


MPoC does not differentiate operating systems as 
supported or unsupported (by the OS vendor). Instead, 
MPoC reguires that all platforms are validated and 
secured regardless of any ongoing support, or end of life 
of that OS. 


An MPoC SDK that executes entirely outside of the REE 
of the COTS device, may allow for rooted and jail-broken 
devices to be included in the COTS platform baseline. In 
such cases, it must be confirmed that the MPoC SDK 
does not allow for sensitive assets, such as account data 
or cryptographic keys, to be exposed in, passed through, 
or obtained from the REE. 
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Security Reguiremenis 


Test Reguiremenis 


3B-1.2.c The tester must confirm through 
examination and observation that, for any MPoC 
SDK that executes in the REE, rooted or jailoroken 
COTS devices are not part of the COTS platform 
baseline. 


3B-1.2.d The tester must confirm through 
observation and interview that the COTS platform 
baseline procedure is actually executed. The 
reguired evidence is an overview of changes to the 
COTS platform baseline. This must include a 
description of the changes, related change 
management tickets and communication to affected 
merchanis. 


Guidance 


— 3B-1.3 The baseline COTS OS must be 
regularly and freguently reviewed for 
vulnerabilities. 


3B-1.3.a The tester must confirm through 
examination, observation, and interview that 
vulnerabilities in the COTS OS are analyzed 
periodically and assessed known and unknown 
vulnerabilities. 


3B-1.3.b The tester must confirm through 
examination, observation, and interview that the 
identified vulnerabilities are mitigated through 
updates to the MPoC Application or A&M, in the 
process of having mitigations implemented, or are 
identified as having no security impact. The reguired 
evidence İS: 


» Recent overview of assessed vulnerabilities 
including verdict. 


» Listof mitigated vulnerabilities. 


It is intended that the vendor identifies the vulnerabilities 
that affect the system baseline. 


It is expected that not all platform vulnerabilities will result 
in risk to MPoC Solutions, but a process to determine if 
this is the case needs to be implemented. It is not 
sufficient for vulnerabilities to be dismissed without 
appropriate research and testing. 


Not all vulnerabilities that affect platforms within the 
COTS baseline reguire specific mitigations. Vulnerabilities 
that are not directiy exploitable or cannot result in 
exposure or risk to the MPoC Solution assets may be 
considered and mitigations deferred until increased risk is 
noted. 

Security review of the COTS OS reguires both threat 
detection and mitigation, as well as vulnerability detection 
and mitigation. This may include detailed review of each 
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Security Reguiremenis Test Reguiremenis Guidance 
3B-1.3.c The tester must confirm through CVE for all supported platforms (in addition to other 
examination, observation, and interview that the measures to identify unknown vulnerabilities), or it may 
freguency of the vulnerability review process is instead be implemented through a combination of focused 
based on an informed risk decision and is no review of known vulnerabilities and robust periodic 
greater than every 3 months. testing. 


For example, use of regular and focused penetration 
testing by mobile security experts instead of review of 
each individual CVE may be sufficient if (i) the testing is 
able to show the efficacy of the security mechanisms, (ii) 
there remains a continuous monitoring of the security 
landscape in between penetration tesis. 


3B-1.4 Personnel involved in maintaining | 3B-1.4.a The tester must confirm through The A&Ms are a combination of automated and manual 

the operation of the A&M must be examination, observation, and interview that the features. Although the A&M software may be developed 

appropriately skilled. personnel involved with the operation of the A&M and maintained by a third party (the MPoC Software 
are appropriately skilled. This must include vendor), the operation of this software will reguire 
personnel skilled with the security of he COTS personnel who are sufficientiy skilled in the platforms 
platforms used in the baseline. used. As the security of COTS platforms is a rapidiy 


evolving field, ongoing training or research is expected for 
the personnel operating the A&MS. 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0 November 2022 
© 2022 PCI Security Standards Council, LLC. All rights reserved. Page 139 


» Security Li 
Standards Council 


Module 3C: Attestation and Monitoring 


This Module contains reguiremenis for the operation of the attestation & monitoring service. 


3C-1 Attestation and Monitoring Policy 


The attestation and monitoring system policy defines what data types are collected during the attestation process, and how this data is 
to be interpreted and managed through the attestation and monitoring componenis of the MPoC Software. 


Security Reguiremenits 


Test Reguiremenis 


Objective: The COTS devices used provide a secure and trustworthy execution environment. 


Guidance 


3€-1.1 A documented attestation policy 
must exist and be demonstrably in use. 


3C-1.1.a The tester must confirm through examination that 
an attestation policy exists and includes the following topics 
at a minimum: 


Roles and responsibilities. 
Data collected during attestation. 
Risk rating of attestation data. 


Follow-up actions and time frames when attestation 
data seem to suggest a tampered component. 


References to specific procedures and/or work 
instructions. 


3€-1.1.b The tester must confirm through examination that 
the attestation component is configured according to the 
attestation policy and attestation and monitoring (A&M) 
integration reguiremenis for the MPoC Software. 


3€C-1.1.c The tester must confirm through examination, 
observation, and interview that the configuration is verified 
periodicalIy. 


The attestation policy outlines what the 
reguiremenis are to ensure that any COTS device 
executing the MPoC Software provides a secure 
execution environment for the MPoC Software. 


The attestation policy differs from the MPoC 
Software guidance documents referenced in 
reguirement 3A-x in that it defines the appropriate 
responses and actions to be performed with 
respeci to the output of the A&M system. 


A monolithic MPoC Solution may not include 
MPoC Software guidance, as it is developed and 
deployed entirely in-house. However, all 
attestation and monitoring systems will always 
have an attestation policy that defines how the 
A&M system operates, the roles and 
responsibilities of those using or on an escalation 
path, how risks are ranked, etc. 


Put another way, the reguiremenis in SA-x 
consider how the A&M system is configured and 
deployed, and the reguirements in this Section 
consider how the A&M system is to be used and 
operated. 
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Security Reguiremenis Test Reguiremenis Guidance 
3C-1.2 If the MPoC Software supports 3C-1.2.a The tester must confirm through examination that Attestation and monitoring functions provided to 
offline transactions, the documented an Offline Attestation Policy exists and it includes ata MPocC Solutions that allow for offline transactions 
attestation policy must contain an explicit || minimum: need to account for the potential operation of 


offline operation mode. those systems while they are disconnected from 
ihe A&M back-end systems. 


Section 1F of this standard details reguirements 


»e (o Checks are enabled when operating in offline mode. 
»* o Theresponses when a security check is triggered. 


» (o Reguiremenis for escalation are noted when offline for the MPoC Software when operating in offline 
transaction processing violates the reguiremenits of mode. This includes preventing offline acceptance 
Section İF. for more than 48 hours, reguiring online 


Ni Ea attestation to be performed prior to enablement of 
3C-1.2.b The tester must confirm through examination, offline mode. as aş reguirements. It is 


observation, and interview that the configuration is verified important that the offline A&M policy outlines the 


periodicaliy. escalation path reguired if any of these functions 
i of the MPoC Software are found to have been 
3C-1.3 If offline operation is implemented, | 3C-1.3.a The tester must confirm through examination and somehow bypassed or violated. 
the offline attestation policy must be observation and interview that the offline provisions in the 
followed. attestation policy are enacted and followed for any system 
operating in offline mode. 
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3C-2 Monitoring 


Attestation data must be analyzed for signs of potential attack or tampering attempits. This monitoring process is an integral part of a 
whole attestation and monitoring solution and must be performed in a secure and repeatable manner. 


Security Reguirements | Test Reguiremenis | Guidance 


Objective: Attestation data is analyzed, and signs of potential attack are consistently responded to in a way that maintains the security and integrity of the 
MPocC Solution. 


3€C-2.1 There must be an overview of the | 3€-2.1.a The tester must confirm through A clear and thorough understanding of the components 

MPocC Solution being monitored. examination that a list of all components that are used in the solution, and how they are being monitored, is 
included in the monitoring process exists and vital. This includes the identification of both OS versions, 
contains references to how these are integrated into | and COTS device types, as the security posture of each 
the A&M. This is reguired to include at least: individual platform may have an impact on the security of 


payment processing. For example, some platforms may 


The platf 
i & PİEMOrMS Süpporled Anel öperaled implement logging of NFC, or touch data at the OS level, 


»  MPoC Application and MPoC SDK (if used) or may provide system applications with higher level 
» (Any attached card reading devices privileges that could result in the compromise of account 
data. 


It is not a reguiremenit that all platforms of concern are 
prevented from accepting paymenis, but such platforms 
may be reguired to undergo additional or enhanced A&M 
checks to verify their secure status. 
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Security Reguiremenis 


3C-2.2 A documented operational 
procedure for monitoring must exist and 
be demonstrabiy in use. 


Test Reguiremenis 


3C-2.2.a The tester must confirm through 
examination that monitoring procedures exist and 
that they contain the necessary information. The 
monitoring procedure needs to include ata 
minimum the following topics: 


» Definition of possible events (warning alerts, 
errors, etc.) from the monitoring system. 


» (How specific evenis are processed. 


» — How undocumented, unexpected, and unknown 
events are handled. 


» Whenandhow events are escalated and when 
the incident management process is initiated. 


» Howit is ensured that personnel are gualified to 
handle events. 


» Referencesto work instructions for the actual 
MPoC Software used. 


3€-2.2.b The tester must confirm through 
observation and interview that the monitoring 
procedures are actualiy executed. The reguired 
evidence is an overview of evenis that have been 
managed. Information about events must include 
date, time, description, and follow up action. 


Guidance 


This reguirement ensures common understanding for 
those involved in the monitoring of the solution. The 
monitoring process may include both manual and 
automated aspecis. 
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Security Reguiremenis 


3C-2.3 The A&M results must be made 
available to the payment processing 
backend. 


Test Reguiremenis 


3C-2.3.a The tester must confirm through 
examination and observation that the A&M provides 
for an indication of A&M results to the payment 
processing backend. 


Guidance 


The A&M provides “health” checks of the COTS platform 
and MPoC Application to ensure the secure operation of 
tihe MPoC Solution. When the attestation and monitoring 
(A&M) checks indicate that there may be a problem with 
any MPoC Application or COTS platform, the A&M 
provides that information to the paymeni processing 
backend so that the continued operation of that specific 
MPoC Application can be determined. 


In cases where there is sufficient information indicating 
that the MPoC Application is at risk of compromise, the 
payment processing backend needs to be informed so 

that payment processing for that MPoC Application can 
be stopped. 


Due to the risk of compromise and interception on the 
COTS platform, signals that may indicate risk of 
compromise of the MPoC Application or COTS platform 
need to be sent to the payment processing backend 
directly. 

This reguirement does not dictate how the attestation and 
monitoring (A&M) results are communicated, but does 
reguire that the results are current and relevant for the 
purposes of determining risk to ongoing transaction 
processing (as attestation results may not be indicative of 
a clear pass/fail result, so risk-based decisions may be 
reguired). 

A&M results may be provided to the payment processing 
backend by programmatic or operational methods. 
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Module 3D: Operational Security 


This Module contains the reguirements regarding the operational security of the A&M back-end systems. 


3D-1 Operational Managemeni 


This Section covers the operational management of the A&M solution. 


Security Reguiremenis 


Test Reguiremenits 


Guidance 


Objective: A&M assets processed in back-end environmenis are secured according to their protection types. 


3D-1.1 When account data is stored, 
processed, and/or transmitted through the 
A&M back-end systems, that environment 
must be compliant to the reguiremenis of 
PCI DSS DESV. 


3D-1.1.a When account data is stored, processed, 
or transmitted through the A&M back-end systems, 
the tester must confirm through examination that the 
environment is compliant to the reguiremenis of PCI 
DSS DESV. 


All systems that store, process, and/or transmit account 
data need to be compliant to the reguiremenits of PCI 
DSS. As attestation and monitoring systems are also 
used to control and manage the security of ibhe COTS 
payment acceptance systems, additional controls are 
reguired for any A&M environment that is not sufficientiy 
isolated from the cardholder data environment. These 
reguiremenits apply in form of PCI DSS DESV controls, 
which are in addition to (or as a supplement to, where 
appropriate) other PCI DSS controls that may already 
apply. 

Validation of PCI DSS DESV compliance may include an 
assessmeni by gualified personnel during the MPoC 
assessmeni, or review of an existing AOC. In all cases, 
ihe scope of the assessmeni is to include the systems 
and environmenis involved in the MPoC Solution. 
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Security Reguiremenis 


3D-1.2 When the back-end A&M, are 
sufficientiy isolated from any other 
systems that store, process, and/or 
transmit account data, the A&M 
environment must comply with the 
relevant reguirements defined in 
Appendix A: Back-end Environment 
Security Reguiremenis . 


3D-1.3 When the A&M service provider 
supports more than one MPoC Solution, 
the assets of the different MPoC Solution 
providers must be segregated. 


Test Reguiremenis 


3D-1.2.a The tester must confirm through 
examination, observation, and interview that 
account data is not stored, processed, or 
transmitted through the back-end A&M, and that 
tihe A&Ms are sufficientiy isolated from any such 
account data processing systems. 


3D-1.2.b The tester must confirm through 
examination, observation, and interview that the 
back-end A&Ms comply with the relevant 
reguiremenis defined in Appendix A: Back-end 
Environment Security Reguiremenis. 


3D-1.3.a The tester must confirm through 
examination and observation that the assets of the 
different MPoC Solution providers are segregated 
when operated by a single A&M service provider. 


3D-1.3.b The tester must confirm through 
examination and interview that the implemented 
segregation controls included in the scope of the 
A&M penetration testing process. 


Guidance 


When the back-end A&Ms are isolated sufficientiy from 
the cardholder data environment, which is used to 
process account data, it is not a reguiremeni that the 
A&M systems also be compliant to PCI DSS. However, 
security conirols are still reguired in the attestation and 
monitoring (A&M) environment, so assessment must be 
made against the reguiremenis provided in the Appendix 
A: Back-end Environment Security Reguiremenis. 


Although not PCI DSS, it is expected that assessmenit to 
Appendix A is performed with appropriately skilled and 
experienced individuals. On-site assessment is to be 
included where appropriate with consideration for any 
remote assessment guidance that may also exist. 


Appropriate separation may include isolation through 
networking controls to prevent the routing or access to 
account data from the attestation and monitoring (A&M) 
environment, or use of cryptographic controls (e.g., 
encryption of account data passed through the A&M 
environment, with no access to the decryption keys or 
functions from within that environmeni). 


The specifics of how any segregation is actually 
implemented is based on a risk assessmenit. This 
reguiremenit does not preclude the pooling of anonymized 
attestation data obtained from different MPoC Solution 
providers for the purposes of increasing the efficacy of the 
A&M detection mechanisms. 

Penetration testing of the A&M service provider 
environment is reguired as part of PCI DSS DESV, or 
Appendix A validation. 
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Domain 4: MPoC Software Management 


The security reguirements and test reguiremenis in this Domain cover the operational management of the software and key management 
aspecis of the MPoC Software. This Domain must be implemented by at least one entity in the MPoC Solution, and there may be multiple 
entities who are reguired to compily with these reguirements. For example, a monolithic MPoC Solution would reguire that the MPoC Solution 
provider is solely responsible for meeting the reguiremenits of this Domain. Alternatively, an MPoC Solution may implement a separately listed 
A&M service provider that has been separately assessed to the reguiremenis of this Domain. 


Module 4A: Software Management 


This Module contains the reguiremenis for the secure operation and management of the software used in an MPoC Solution. This includes 
any MPoC SDK, A&M Software, and MPoC Application(s). 


4A-1 COTS Software Distribution and Updates 


Software that is to be installed and executed on the COTS device for an MPoC Solution needs to be compliant to this Section. This 
includes the MPoC Application that integrates the MPoC SDK, or the MPoC SDK itself if it is instantiated and distributed as a stand- 
alone MPoC Application. Unlike Domain 2 of this standard, which covers the development and software of the MPoC Application, this 
Section covers the operational aspecis of distributing and maintaining an MPoC Application. This includes any ongoing key 
management reguiremenis, as well as the reguiremenits for the secure distribution of the MPoC Application(s). 


These reguirements do not dictate any specific type of distribution method for the MPoC Application, such as a dedicated OS Store, but 
they do outline the minimum reguiremenis that any method used to distribute the MPoC Application must meet. This includes any initial 
loading of an MPoC Application to a COTS Platform as part of the manufacturing or pre-sales provisioning of that COTS platform. 
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Security Reguiremenis 


Test Reguiremenis 


Objective: Software is securely provisioned to, and maintained on, the COTS device. 


Guidance 


i 4A-1.1 Information about how software is 
provisioned securely to the supported 
COTS devices must exist. 


4A-1.1.a The tester must confirm through 
examination that the information provided includes 
at a minimum: 


The supported MPoC Application distribution 
methods. 


How the MPoC Application distribution methods 
supported are protected. How access to MPoC 
Application distribution methods is protected 
(for the purposes of uploading or changing 
security sensitive settings). 


How the data provisioned after the MPoC 
Application is installed and the purpose of that 
data. This includes executable files and 
configuration files. 


The protection of the MPoC Application during the 
provisioning lifecycle stage is needed to prevent the 
distribution of a malicious MPoC Application. 
Documentation covering the MPoC Application 
distribution, and provisioning helps to identify 
vulnerabilities in this stage of the MPoC Software 
lifecycle. 


The MPoC Application distribution method may include 
the OS store of the COTS device, or an MDM solution. 
Regardless of what method is used, MPoC Applications 
are to be distributed in a secure manner, and in a way 
that protecis their integrity and authenticity. 


Attackers may attempt to alter MPoC Application updates 
as they are transferredto a COTS device, or by altering 
the MPoC Application file in the store prior to distribution. 
In cases where the MPoC Application vendor is unable to 
verify or validate sufficient security in any particular 
distribution method, an alternative method of distribution 
is to be used. 

COTS platforms that are not able to provide any method 
for MPoC Application distribution that is sufficiently secure 
are not sultable for use. 
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Security Reguiremenis 


4A-1.2 The MPoC Application must be 
installable and updatable exclusively 
through the defined COTS application 
distribution methods. 


Test Reguiremenis 


4A-1.2.a The tester must confirm through 
examination and observation that it is not possible 
to perform transactions on an MPoC Application 
loaded onto the COTS device through means other 
than the defined COTS application distribution 
methods. 


Guidance 


The authenticity of the MPoC Application is a paramount 
concem in securing account data. Loading of applications 
from the OS store provides a level of confidence that the 
application has not been tampered with before being 
installed on the merchant COTS device. 


In some OS$, it is possible to perform “side-loading” of 
applications — that is, install them separate to the normal 
application distribution methods and controls — at any 
time by configuring the COTS device to allow for this 
process. In other OSs, it may be necessary to establish a 
developer account or perform some other actions on the 
COTS device to allow for loading of applications outside 
the distribution store formally supported by the MPoC 
Solution. 


It is necessary to outline what processes are available to 
bypass the supported store(s) and confirm that these 
methods do not allow for the loading of an MPoC 
Application that will operate normalIy. 


4A-1.3 The interface to each of the 
implemented MPoC Application 
distribution methods must be protected. 


4A-1.3.a The tester must confirm through 
examination that controls are implemented to 
prevent the compromise of any MPoC Application 
distribution channels used. 


To distribute an MPoC Application, it must first be 
distributed to a COTS application distribution method. The 
upload access that MPoC Application vendors have with 
ihe COTS application distribution method is reguired to be 
protected to prevent tampering or replacement of the 
MPoC Application at this stage of the lifecycle. This can 
be done by limiting and securing the access that the 
MPoC Application development team and others have to 
the distribution channel. 
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4A-1.4 The methods implemented to 4A-1.4.a The tester must confirm through Only authentic MPoC Applications are permitted to be 
distribute the MPoC Application must examination and observation that all the methods installed and operated as part of an MPoC Solution. The 
provide authenticity to the MPoC supported for distribute the MPoC Application authenticity at installation time needs to be provided by 
Application prior to initial execution. provide authenticity prior to initial execution. tihe MPoC application defined distribution method and/or 


COTS platform, before the MPoC Application is executed 
for the first time following installation or updating. 


COTS platforms that do not allow for the use of a COTS 
application distribution method that can provide 
authenticity to the MPoC Application at installation time 
are not suitable for use with an MPoC Solution. 


The minimum reguiremenis for the COTS platform 
baseline — including the need to support validation of a 
digital signature across MPoC Applications that are 
Ioaded onto the device — is covered in reguirement 3B-x. 


Some COTS platforms may support multiple signature 
types or allow for the use of self-signed certificates. The 
intent of this reguirement is not to enforce that all 
signatures chain up to an authorized Certificate Authority, 
but that the COTS application distribution methods 
implemented provide for the ability to validate that the 
MPoC Application has not been maliciously modified 
since deployment to (and through) the COTS application 
distribution method. 
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4A-1.5 The MPoC Application must 4A-1.5.a The tester must confirm through The defined COTS application distribution method may 

include methods to allow for the merchant | examination and observation that the MPoC not guarantee that the application that is provided is 

to validate the authenticity of the MPoC Application implements methods to permit the genuine, instead simply providing confirmation that it did 

Application. merchant to validate the authenticity of the MPoC indeed come from the COTS application distribution 

Application. method used. Therefore, the merchant needs to be able 

to separately validate the authenticity of the MPoC 
Application. 


Some COTS Platforms may support self-signed 
certificates, and it is not a reguiremeni for a signature tO 
chain up to an authorized Certificate Authority. Because 
of this, it is necessary that the merchant is able to 
separately validate that the MPoC Application they have 
downloaded is not just a valid application, but is the 
MPoC Application they intended to download and use for 
paymenit acceptance. 


This reguirement is intended to help secure MPoC 
Solutions against fake or “look-alike” MPoC Applications, 
created for the purpose of capturing payment data for 
malicious use. There are many ways in which this 
objective may be met, e.g., by using an out-of-band 
method (such as a website or phone number) to perform 
a challenge-response process with the MPoC Application, 
or by using the ability of the MPoC Application to 
communicate to an attached device, such as a PCI PTS 
SCRP, as confirmation it is indeed the valiJ MPoC 
Application. 
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4A-1.6 The MPoC Application vendor 4A-1.6.a The tester must confirm through The MPoC SDK may be developed by an entity different 
must implement a distribution method that | examination that the MPoC Application vendor than that which develops and maintains the MPoC 
provides secure and timely updates ofthe | provides secure updates of the MPoC SDK Application. Even if the same entity produces both the 
MPoC SDK. according to the MPoC Software security guidance MPoC Software and the MPoC Application, there may be 
document. separate teams Or resources used for each. 
Note: This reguirement is concerned with the In such scenarios, it is possible that the MPoC SDK has 
operational process of communicating and an update process and timing that are dislocated from 


delivering updates, not with the technical process of | that of the MPoC Application. 


maintaining and updating MPoC Software. The MPoC Software vendor is reguired to keep MPoC 
Application vendors informed of releases and changelogs 
as part of their validation and listing. MPoC Application 
vendors are reguired, on their part, to have procedures in 
place to coordinate the incorporation of new MPoC 
Software releases, including configuration settings. 
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4A-2 Key Management Operations 


Encryption is relied upon as a foundational control in many MPoC security reguirements. Security of the cryptographic keys, certificates, 
and systems used with these operations is of egual importance to the actual cryptographic algorithms used. This reguirement applies to 
all operational aspecis of key management, including those performed by A&M service providers, MPoC Solution providers, and MPoC 


Software vendors. 


Security Reguiremenits 


| Test Reguiremenis 


| Guidance 


Objective: Cryptographic keys and certificates are managed securely throughout their complete lifecycle. 


4A-2.1 Procedures to generate, distribute, 
revoke, and renew keys and certificates 
must follow the MPoC Software security 
guidance and be demonstrabiy in use. 


4A-2.1.a The tester must confirm through 
examination, observation, and interview, that 
procedures for the generation, revocation, and 
renewing of keys and certificates follow the MPoC 
Software security guidance and are demonstrabiy in 
use. The procedures must, at a minimum, include 
the following topics: 


» Relation to incident managemeni processes. 


» oAssessmentof impact of key replacement 
(replacement of a root CA key will have more 
impact than a device specific key). 


» Communication to stakeholders. 


» (Work instructions about how to actually revoke 
and renew specific keys and certificates. 


The MPoC Software implements cryptography for various 
conitrols, and this implementation is assessed under the 
reguiremenits of Domain 1. However, to ensure the 
security of the MPoC Solution, the ways in which the 
cryptographic systems are used and operated are also 
important. 


This includes any processes that involve the generation, 
revocation, renewal, and distribution of cryptographic 
keys. Operational aspects of an MPoC Solution are not 
permitted to implemeni their own cryptographic systems 
or protocols separately from those already implemented 
within the MPoC Software. 


This reguirement covers the operational aspecis of the 
key management already implemented in the MPoC 
Software design. The expectation is that no additional or 
altered key management has been implemented during 
implementation, and that the operational aspecis of the 
existing key management are performed in an expected, 
secure, and compliant manner. 
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4A-2.2 Secret or private cryptographic 4A-2.2.a The tester must confirm through Cryptographic keys need to be protected to prevent 
keys used for the security of the solution examination and observation that cleartext secret or | unauthorized or unnecessary access that could result in 
in the back-end environments must be private cryptographic keys in the back-end the exposure of encrypted data. 
protected through use of HSMs compliant | environmenis are stored and processed only in Secret or private cryptographic keys need to be stored in 
to FIPS140-2/3 level 3, or PCI HSM HSMSs compliant to FIPS140-2/3 level 3 (or above), | an encryptedform or within an SCD, such as an HSM. 
reguiremenis. or PCI HSM reguiremenis. This reguirement applies to all keys used to encrypt PINs 


and other account data, as well as cryptographic keys 
used to secure attestation data. The reguiremeni for HSM 
use does not apply to cryptographic keys used for the 
establishment and security of secure channels, such as 
TLS keys. Cryptographic keys used for signing MPoC 
Applications, or that are used for creating software 
protected cryptography implementations, are also out of 
scope of this reguiremenit. 


4A-2.3 Work instructions to operate 4A-2.3.a The tester must confirm through It is of vital importance that HSM's are operated as 
HSMSs exist and are demonstrably in use examination that HSM operational work instructions | prescribed by the HSM supplier. Documented work 
for each type of HSM used. exist and contain the following topics ata minimum: | instructions help to prevent human failures. 
» (o Confirmation of HSM security and operational Keys that are reguired to be protected using HSMs do not 
state include cryptographic keys used for secure channels, 


such as TLS keys. Application-level keys are included in 
scope and need to be protected by HSMS. 


j Confirmation of the security and operational state of the 

» oKeyimport HSMs may include physical observation or examination 

» oKeyexport by the A&M service provider, or remote cryptographic 
means where physical observation is not possible (e.g., in 
Cloud HSM environmenis). 


e (o Authentication/Authorization 
» Key generation 


» Keydeletion 
»e (o Auditlogreview 
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4A-2.4 If the back-end systems include 4A-2.4.a The tester must confirm through Cloud service providers offer different ways to manage 
ihe use of cloud-based HSM's, the examination and interview that cryptographic keys HSM keys. In general, three options are supported: 
cryptographic keys are managed by are generated and managed by the Cloud HSM » © Keys are generated and managed by the Cloud 
relevant MPoC entity, and not accessible | user, and not accessible to the Cloud HSM service service provider. Depending on the HSM type, this 
to the Cloud HSM provider. provider. could even mean that HSM keys are shared with 


4A-2.4.b The tester must confirm through Ebe LOM er 


examination, observation, and interview that »* Keys are generated and managed by the Cloud HSM 

cryptographic keys used in the back-end systems user, but within the cloud environment. The keys are 

are not exposed outside of any cloud HSMs used in not shared with other customers, but security 

the solution. depends on the Cloud service providers' 
configuration. 


» Keys are generated by the Cloud HSM user in their 
own premises and the transferred securely to the 
Cloud service provider. 


Some Cloud HSM systems use the HSM only for storage 
of keys and allow for export of keys for cryptographic 
operations. These types of Cloud HSM systems are 
unsultable for use with MPoC Solution. 


Keys that are reguired to be protected using HSMs do not 
include cryptographic keys used for secure channels, 
such as TLS keys. Application-level keys, including those 
keys used to encrypt A&M data sent to the back-end A&M 
environment, are included in scope and need to be 
protected by HSMS. 


4A-2.5 Operational key management of 4A-2.5.a The tester must confirm through Cryptographic keys are reguired to be protected against 
secret and private cryptographic keys examination, observation, and interview that secret unauthorized disclosure. This includes ensuring keys are 
must ensure the confidentiality of ihe keys | or private keys in the solution are maintained in one | always managed in one of the “approved forms” as listed 
throughout their lifecycle. of the permitted forms throughout their lifecycle. in this test reguiremenit. 
Permitted key forms are: This reguirement applies to all keys used to encrypt PINs 
» Enciyptedbya key encryption key of egual or and account data, as well as cryptographic keys used to 
greater strength (these key encryption keys secure attestation data. The reguirement for HSM use 
need to satisfy this reguiremeni). does not apply to cryptographic keys used for the 
“hi establishment and security of secure channels, such as 
e TLS keys. Cryptographic keys used for signing MPoC 
» o Managedasitwoor more fuli-length Applications, or that are used for creating software 
componenis. protected cryptography implementations, are also out of 


»e o Managedasan M-of-N secret-sharing scheme. | scope of ihis reguiremeni. 
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Security Reguiremenis 


4A-2.6 Operational management of 
cryptographic keys must ensure the 
integrity and authenticity of the keys 
throughout their lifecycle. 


Test Reguiremenis 


4A-2.6.a The tester must confirm through 
examination, observation, and interview that all keys 
in the solution have their integrity and authenticity 
protected. 


Guidance 


Cryptographic keys are to be protected against 
unauthorized or unintentional change. For example, this 


can be achieved by: 


» (o İmplementing cryptographic controls such as key 
blocks. Key blocks may be implemented entirely in 
the back-end systems, or in concert with the MPoC 


SDK (refer reguiremenits in 1A-x). 


» (o İmplementing key check value or key fingerprint 


verification processes. 
» Managing public keys in certificates. 


4A-2.7 Management of secret and private 
cryptographic keys must implemenit the 
principles of dual control and split 
knowledge. 


4A-2.7.a The tester must confirm through 
examination, observation, and interview that dual 
control and split knowledge are implemented in the 
organization to manage secret and private 
cryptographic keys. 


Split knowledge reguires that no individual has any 
information about any part, even a single bit, of the 
cleartext key. Dual control reguires at least two individuals 
to perform a process, as it is more difficult to establish a 
breach of process or information when multiple entities 


are reguired to conspire to misuse. 


There are several ways to implement dual control and 
split knowledge using logical mechanisms, physical 
mechanisms, or both. This reguirement does not enforce 
the need for manual processes for keys that are instead 


always secured within an SCD. 


Depending on the number of cleartext components there 
may be different groups of key custodians, although it is 
reguired that there always be more than one. No one 
individual can ever have access to enough key 
componenis to reconstruct any part of the cryptographic 


key. 


For key custodians to be free from undue influence in 
discharging their custodial duties, different key custodians 
who are able to form the necessary threshold to create a 
key are not permitted to directly report to the same 
individual, except for organizations of insufficient size. 
Key custodians need to have regular security awareness 


training. 
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4A-2.8 Mechanisms must be in place to 4A-2.8.a The tester must confirm through Expired certificates can introduce unacceptable risk to the 
identify expired, invalid, or and revoked examination and observation that a revocation solution. Payment functions are reguired to be halted 
certificates, and to prevent continued mechanism exists and is effective in preventing the | when certificates that are relied upon have expired or are 
processing using certificates that have use of revoked and/or certificates. otherwise detected as no longer valid. Expired certificates 
expired or been revoked. may be an indication of a malicious user acting as an 


imposter of a legitimate organization or process who is 
phishing for sensitive information. 


Many security incidents are caused by expired or revoked 
certificates. While understanding of the keys used is 
important and collected in the key/certificate tables, it is 
egually important to have procedures to act upon if any 
key expires or is suspected of being compromised. 


The reguirement is applicable to all componenis of the 
solution and includes only the certificates upon which the 
solution relies for security purpose. 
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4A-3 Penetration Testing and Vulnerability Management 


These reguirements cover the reguiremenis for penetration testing and vulnerability management for MPoC A&M service providers, and 
MPoC Solution providers. 


Security Reguirements Test Reguiremenis | Guidance 


Objective: Back-end environments cannot be compromised from within an authenticated MPoC Application session. 


4A-3.1 A penetration test must be 4A-3.1.a The tester must confirm through All back-end eniry points meant to parse and process data received 
performed on the interfaces between | examination that a penetration test has been from the MPoC Software are reguired to have undergone 
the MPoC Application or MPoC SDK, | performed on the interfaces between the penetration testing. This includes the payment and PIN processing 
and back-end environmenis (e.g., MPoC Application, or an MPoC SDK ina backends, as well as any cloud/remote kernel systems used, where 
A&M, payment processing and/or suitable test application, and back-end these are part of the MPoC Solution. 
remote kernel) prior to the validation environmenis prior to initial deployment, and This penetration test differs from the test reguired in 1A-1.3 in that it 
and listing of an MPoC Solution or at least annually thereafter. Penetration testing | is to be performed in the context of a malicious MPoC Application, 
A&M service provider, and at least reports must be examined to confirm that he | | oran MPoC SDK'in a suitable test application, using a valid and 
once per year thereafter. scope covers all aspecis of the MPoC authenticated secure channel to back-end systems. The testing is 
Solution, or A&Ms, and that any major intended not to re-assess the security of the MPoC Software, but 
vulnerabilities found during the penetration instead that the MPoC Software has been securely integrated into 
testing have been remediated. the other systems and software of the overall MPoC Solution. 
Because this is an operational compliance reguiremeni, it İS 
expected that source code and other details of the logical aspects of 
tihe MPoC Solution may not be available for this penetration test. 
(continued on next page) 
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4A-3.2 A security-flaw-reporting 4A-3.2.a The tester must confirm through Penetration testing and vulnerability management processes are 
program must be implemented to examination that a vulnerability-reporting expected to be part of any secure software lifecycle process. This 
encourage the finding and reporting program exists for the system, and there is reguirement confirms the scope and efficacy of the penetration 
of vulnerabilities by internal and evidence of accepting and remediating testing as it is applied to a complete MPoC Solution or an A&M 
external entities. security vulnerabilities found through this service provider, as it has integrated and operates the MPoC 
program. Software. 


A penetration test is considered to be a clearly scoped and 
deliberately engaged activity performed on behalf of the MPoC 
Solution provider, or A&M service provider. This differs from the ad 

ale Ri hoc testing that may be performed as part of a vulnerability 
examination that any such vulnerabilities are 


5 management or flaw reporting program. 
processed through the vendor risk-and-update i : ' 
process and patched accordingiy. Penetration tests need to be performed by suitabiy skilled resources 


and may be performed by resources internal to the entity if such 
resources exist. When penetration testing is performed by internal 
resources, the people performing the testing need to be separate 
from those who perform any operation, development, or integration 
work. 


Skills expected from the resources used for penetration testing 
include an understanding of EMV protocols and payment 
processing, skills and experience with mobile security and 
communications protocols, and a clear history of penetration testing 
experience. 


Results from annual penetration testing may not exist for newly 
deployed MPoC Solutions, or A&M service providers, but need to be 
provided for any review performed after the first year after their 
initial validation. However, an initial penetration testing report is 
reguired to be available prior to validation and listing of the MPoC 
Solution or A&M service provider. 


Penetration testing may be performed by the same entity that 
performs the MPoC evaluation, but the MPoC evaluation itself 
cannot be considered a penetration test to meet this reguirement. A 
separate testing and reporting process must be implemented for this 
penetration test. 


4A-3.2.b For any vulnerabilities have been 
reported through the security flaw reporting 
program the tester must confirm through 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0 November 2022 
© 2022 PCI Security Standards Council, LLC. All rights reserved. Page 159 


» Security Li 
Standards Council 


Domain 5: MPo€C Solution 


The security reguiremenits and test reguiremenis in this Domain cover the operational management of the complete MPoC Solution. This 
includes the validation of compliance for the paymenit-processing environment, the PIN-processing environment, the MPoC attestation and 
monitoring environment, and any other systems such as the split kernel environment. 


Where the paymenit-processing and PIN processing are not performed by the MPoC Solution Provider those aspects may be considered out 
of scope of the assessmenit. Only those aspecis that are included—e.g., a payment switch operated by the MPoC Solution provider—are to be 
included in the assessment of this Domain. However, it is not possible for an MPoC Solution that allows for PIN entry on the COTS device to 
never include validation of a PIN processing environment. Egually, it is also expected that all MPoC Solutions will include decryption or key 
management environmenis for account data seni from the MPoC Applications that are deployed as part of the MPoC Solution. 


Although it is not necessary for the MPoC Solution provider to develop, implemenit, or operate all of these systems, it is the responsibility of the 
MPoC Solution provider to ensure that the relevant reguiremenis for each are met. This may be achieved through a monolithic solution, where 
ihe MPoC Solution provider is responsible for the assessment and compliance of all aspects of the overall MPoC Solution, or through a 
composite solution where the MPoC Solution provider utilizes separately assessed and listed MPoC Products. In all cases, the MPoC Solution 
provider remains responsible for the compliance and security of the entire MPoC Solution. 
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Module 5A: Third Party Management 


This Module contains the reguirements regarding the management of third parties. 


54-1 Merchant Identification and Communication 


MPoC Solutions are used by merchants to accept payment transactions. Initial provisioning of the MPoC Application includes providing 
for the unigue identification of the merchant. Ensuring that the merchant is informed of changes or reguiremenis of the MPoC Solution 


as the solution changes over time is vital to the security of the solution. 


Security Reguirements Test Reguiremenis 


| Guidance 


Objective: The merchant is onboarded securely and kept up to date with relevant information in a timely manner. 


5A-1.1 The process of onboarding new 5A-1.1.a The tester must confirm through 
merchants must be documented. Ata examination that the onboarding process is 
minimum, the process must describe how | documented. 

merchant identification is performed. 


5A-1.2 The merchant-onboarding process | 5A-1.2.a The tester must confirm through 

must include the provisioning of a unigue | examination that the provisioning process is 
merchant identifier, and the provisioning documented and describes how the unigue 
process of this unigue merchanit identifier | merchanit identifier is created and provided to the 
must be documented. merchant. The tester must confirm that the reguired 
controls are implemented. 


The following topics must be present at a minimum: 
» (How the unigue merchant identifier is created 
securely. 


» oThatany user credentials that are transmitted 
must not be sent together. 


Identification is an important security measure against 
financial fraud to verify the identity, suitability, and risks 
involved with maintaining a business relationship with the 
merchant. 


This reguirement is not intended to cover the legal or 
financial process of merchant on-boarding, but to ensure 
merchants are uniguely identified to help facilitate the 
A&M systems and any communications reguired. 


This reguirement is primarily concerned with the data 
used to uniguely identify the merchant to the payment 
system. It does not reguire that the MPoC Application 
must implement a per-user password or other such 
identification system. 


However, if any passwords or other credentials are 
implemented, they must be transmitted and processed 
securely. 


Fraudulent activities often start with unauthorized access 
to credentials. The provisioning process is a particularly 
vulnerable process in the solutions. Well-known 
measures to improve the security of this process use 
separate channels and special PIN/password letters, and 
do not send user IDs and passwords together. 
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Security Reguiremenis 


5A-1.3 A merchant communication plan 
must exist and be demonstrably in use, 
that includes how and when information is 
shared with merchants and detail the 
information and trigger points that result in 
such communication. 


Test Reguiremenis 


5A-1.3.a The tester must confirm through 
examination that a merchant communication plan 
exists and contains the following information at a 
minimum: 


Changes to the system baseline. 
Changes to any user manual including at a 
minimum: 

— Howthe MPoC Application must be 
installed and provided with unigue 
(configuration) data. 

— Howtousethe MPoC Application 
securely (e.g., privacy during the 
customer PIN eniry process). 

— Any security responsibilities that belong 
to the merchant when using the 
Solution. 

— Üser information about peripheral such 
as non-PTS approved MSR or PCI PTS 
SCRP if used in the Solution. 

— Howtocontactthe MPoC Solution 
provider. 

Planned maintenance downtime 
Provisioned credentials 


Information about potential compromise/security 
incidents 


End User License Agreement (EULA) 


5A-1.3.b The tester must confirm through 
examination that the merchant communication plan 
is demonstrabiy in use, for instance, by examining 
previously issued merchant communication (for 
MPoC Solutions that are already in use). 


Guidance 


It is important that the merchant receives relevant 
information in a timely manner, and this process cannot 
be performed ad hoc when issues arise. A merchant 
communication plan ensures that the processes for how 
and when to communicate to the merchant base are 
detailed, so all parties are aware of their obligations. 
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5A-2 Support for Multiple Entities in the Solution 


The MPo€ Solution is comprised of multiple different componenis, such as tihe MPoC Software, MPoC Application, the A&M backend, and the 
paymeni-processing backends. There must be a clear process for understanding and defining the reguirements and roles and responsibility of 


each entity involved. 


Security Reguiremenits 


Test Reguiremenis 


| Guidance 


Objective: Formal processes exist to define and align the interaction and roles of the different entities in the MPoC Solution. 


5A-2.1 Documentation must exist that 
describes how the operational processes 
are aligned between the different entities 
in the MPoC Solution. 


5A-2.1.a The tester must confirm through 
examination that documentation on cooperation 
exists and that it contains the reguired information. 


Documentation must contain the following at a 
minimum: 
» oContactinformation of all entities involved. 


» (o Agreemenison incident management 
processes. 


» (o Agreemenison escalation processes. 


The Solution might be operationally managed by different 
entities. This often leads to problems in case of incidents 
covering more than one entity. Agreemenis on these 

kinds of topics help to solve potential incidents efficientiy. 


For example, in the case where a specific COTS Platform 
is removed from the A&M baseline due to security 
concerns, it must be clear how this process of removal is 
to be handled between the various parties who comprise 
the MPoC Solution. 


5A-2.2 The MPoC Applications deployed 

by the MPoC Solution must be supported 

by the Attestation and Monitoring systems 
implemented. 


5A-2.2.a The tester must confirm through 
examination that the MPoC Applications deployed 
by the MPoC Solution are supported by Attestation 
and Monitoring Services (or internal systems) 
implemented. 


An MPocC Solution may be comprised of multiple MPoC 
Software products, or a combination of MPoC Software 
Products and monolithic MPoC Applications. 


To ensure that the security of the MPoC Solution is 
maintained, it is important that the MPoC Applications 
deployed are supported by the Attestation and Monitoring 
Services (or internal systems) used by the MPoC 
Solution. 


For example, it would not be acceptable for an MPoC 
Solution to use the MPoC SDK from MPoC Software 
Product A, but not use an Attestation and Monitoring 
Service (or internal system) that also supports that same 
MPoC Software Product. 
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5A-3 Security of Back-end Systems 


Back-end environmenits used as part of an MPoC Solution are secure and maintained in compliance with relevant standards or 


reguiremenis. 


Security Reguirements 


Test Reguiremenis 


Guidance 


Objective: Back-end environment are implemented and operated securely and in ways that maintain compliance to other applicable standards. 


5A-3.1 Environmenits that store, process, 
or transmit account data must comply with 
the reguiremenis of PCI DSS. 


5A-3.2 Environments performing PIN 
processing, or manage PIN related 
cryptographic keys, must comply with the 
reguiremenis of PCI PIN. 


5A-3.1.a The tester must confirm through 
examination that a valid Attestation of Compliance 
(AOG) outlining compliance of any environment 
within the MPoC Solution that stores, processes, or 
transmits account data with the PCI DSS 
reguiremenis. 


5A-3.2.a The tester must confirm through 
examination that a valid AOC outlining compliance 
of any PCİ PIN-processing environment included in 
the MPoC Solution exists and is current and upto 
date with the features provided. 


5A-3.2.b The tester must confirm through 
examination that the key-loading facilities used for 
any PCI PTS devices implemented in the MPoC 
Solution are included in the PCI PIN compliance 
scope. 


Environmenis that are PCI DSS compliant demonstrate 
that the minimum set of industry-expected security 
controls have been applied to that environment, which 
reduces risk compared to environments that do not apply 
security conirols. 


This includes any payment processing backends directiy 
implemented by the MPoC Solution, or where there is the 
ability for the MPoC Solution systems to have access to 
cleartext account data, or the cryptographic keys that can 
be used to decrypt any encrypted account data. 


Environmenis that are PCI PIN compliant demonstrate 
that the minimum set of industry-expected security 
controls have been applied to that environment, which 
reduces risk compared to environmenis that do not apply 
security conitrols. 

Specific non-compliances raised as part of PCI PIN 
validation, due to the use of an MPoC Solution, need to 
be considered when assessing this reguirement. 


i 5A-3.3 All remote kernel environmenis 
implemented by the solution must comply 
with PCI DSS reguiremenis. 


5A-3.3.a The tester must confirm through 
examination that a valid Attestation of Compliance 
(AoC) outlining compliance of the remote kernel 
environment(s) with the PCI DSS reguiremenits. 
This AOC must cover the scope of the remote 
kernel processing environment. 


Environmenis that are PCI DSS compliant demonstrate 
that the minimum set of industry-expected security 
controls have been applied to that environment, which 
reduces risk compared to environments that do not apply 
security conitrols. 
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5A-3.4 The A&M environment must 5A-3.4.a The tester must confirm either that the The A&M environment may be operated by a service 
comply with the reguirements in Domain 3 | A&M environment complies with the reguirements of | provider who already has been assessed and is listed as 
of this standard. Domain 8 of this standard or that the A&M service comypliant to these reguiremenis. Otherwise, the 
provider is listed on the PCI website as an approved | reguirements in Domain 83: Attestation and Monitoring 
A&M service provider. apply. 
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Appendix A Back-end Environment Security Reguirements 


Recognizing that back-end attestation systems that support the MPoC Solution may not be in scope of PCI DSS, this appendix defines the 
minimum reguiremenis to ensure fundamental security of the back-end monitoring system and back-end attestation component. 


This appendix is referenced through test items outlined previously in the MPoC standard, where security assurance of those systems İs 
reguired, but assessment to PCI DSS is not otherwise in scope. Where assessment against the reguiremenis in this appendix is to be 
performed, the MPoC laboratory must confirm that all relevant systems and personnel are included. This may include subsets of all possible 
systems or personnel if sufficient clarity on the systems and operations of the environment can be determined. The term “all personnel” as 
used within these reguiremenis refers to all personnel deemed to be in scope by the MPoC laboratory. 


Assessmenis to Appendix A are expected to be performed by suitabiy gualified individuals and cannot be performed as a self-assessment. 
Remote assessments may be performed to Appendix A, if in line with current PCI SSC guidance on remote assessmeni processes. 


Table 5: Mapping of Appendix A Security Reguiremenits to PCI DSS Reguirements 


Appendix A Security Reguirements PCI DSS Reguiremenis (from PCI DSS v3.2.1 & PCI DSS v4.0) 


A1. Maintain security policies for all personnel Reguirement 12 


A2. Secure network connectivity Reguiremenit 1 
Reguirement 10 
Reguirement 11 


A3. Develop and maintain secure systems Reguiremenit 2 
Reguirement 6 


A4. Vulnerability management Reguirement 5 
Reguirement 6 
Reguirement 11 


A5. Manage access Reguirement 7 
Reguirement 8 


A6. Physical security Reguirement 9 


A7. Incident response preparedness Reguirement 10 
Reguirement 12 
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A.1 Maintain Security Policies for All Personnel 


Security Reguirements 


Test Reguiremenis 


Guidance 


Conirol Objective: Security policies define rules and reguiremenis for all personnel to protect the security and integrity of the entity's resources and protect 


against identified risks. 


i A.1.1 Security governance 


A.1.1.1 Security objectives are aligned with 
business objectives. 


Examine documentation. 
Interview personnel. 


The security objectives need to be defined as part of an 
overarching security strategy that supports and facilitates 
business objectives. The security strategy needs to 
provide the foundation for the entity's security policies and 
procedures and provide a benchmark against which the 
health of security controls is monitored and measured. 


A.1.1.2 Responsibilities and accountability 
for meeting security objectives are assigned 
formally, including responsibilities for the 
security of the environment. 


A.1.1.3 Responsibility for identifying and 
addressing evolving risks is assigned. 


Examine documentation. 
Interview personnel. 


Examine documentation. 
Interview personnel. 


The assignment of specific roles and responsibilities need 
to include monitoring and measurement of performance to 
ensure security objectives are met. Roles and 
responsibilities may be assigned to a single owner or 


multiple owners for different aspecis. 


Ownership needs to be assigned to individuals with the 
authority to make risk-based decisions and upon whom 
accountability rests for the specific function. Duties are 
reguired to be defined formally, and owners must be able 
to demonstrate an understanding of their responsibilities 


and accountability. 
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Security Reguiremenits 


A.1.2 Maintain security policies 


Test Reguiremenis 


Guidance 


A.1.2.1 An organizational security policy(s) 
is established and disseminated to all 
relevant personnel. 


A.1.2.2 Security policies are reviewed and 
updated as needed to reflect changes to 
business objectives or the risk environment. 


A.1.2.3 Policy updates are communicated to 
applicable personnel. 


A.1.2.4 The security policy is approved by 
management. 


» (Examine documented policies and 
procedures. 


» (o İnterview personnel. 


A.1.2.5 An organizational security policy(s) 
is established and disseminated to all 
relevant personnel. 


» (Examine documented policies and 
procedures. 


» (o İnterview personnel. 


A strong security policy, or policies, set the security tone 
for the entity as a whole and inform personnel what is 
expected of them. All personnel must be aware of the 
sensitivity of data and their responsibilities for protecting 
it. The security policy needs to be updated as neededin 
response to changes in the environmeni, results of risk 
assessmenis, implementation of new technologies, and 
changes in business objectives. 


Personnel must be aware of all policies and policy 
updates, including their applicable responsibilities. 
Methods of communicating policies need to include a 
mechanism for personnel to acknowledge they have 
received and read the policy or policy update. Personnel 
acknowledgment may be in writing or electronic. 


All security policies and policy updates must be approved 
by management to ensure alignment with the entity's 
security strategy and business objectives. Any exception 
to the policies reguires management sign-off to ensure 
the appropriate due diligence is done and approval 
obtained. 


A.1.3 Evaluate risk 


A.1.3.1 A risk-assessmeni process is 
documented. 


A.1.3.2 The documented risk-assessment 
process is performed at least annually and 
upon significant changes. 


» (Examine documented policies and 
procedures. 


»e (o İnterview personnel responsible for risk- 
assessmenit process. 


Risks to environments must be assessed at least annually 
and upon significant changes. The risk assessment İs 
reguired to identify assets, threats, likelihood, and 
potential impacts. Risk considerations need to include 
internal and external attacks (e.g., for cybercrime, fraud, 
or theft), internal control failures, and malware. Risks 
must be prioritized and resources allocated to implement 
controls that reduce the likelihood and/or the potential 
impact of the threat being realized. Considerations are 
reguired to include regulatory obligations and changes in 
technology (e.g., deprecation of encryption algorithms). 
Note: Examples of risk-assessment methodologies 


include but are not limited to OCTAVE, ISO 27005 and 
NIST SP 800-30. 
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Security Reguiremenis | Test Reguiremenis 


A.1.4 Manage risk 


Guidance 


A.1.4.1 A formal risk-managemenit strategy 
is defined. 


Examine documentation. 
» (o İnterview personnel. 


The risk-managemeni strategy defines a structured 
approach for identifying, evaluating, managing, and 
monitoring risk. The strategy is reguired to include 
reguiremenis for regularly reviewing and updating the 
entity's risk-assessment processes as well as methods to 
monitor the effectiveness of risk-mitigation controls. 


A.1.4.2 The risk-managemeni strategy is » Examine documentation. 
approved by authorized personnel and 3 
updated as needed to address changing risk 
environment. 


Interview personnel. 


The risk-management strategy needs to be approved by 
personnel with appropriate responsibility and 
accountability. 


A.1.5 Manage third-party relationships 


A.1.5.1 Policies and procedures for » Examine documented policies/procedures. 
managing third-party relationships are 3 


© n Interview personnel. 
maintained and implemented. 


A.1.5.2 Due diligence is performed prior to » (Examine documented procedures. 
any engagement with a third party. » oExamineresults of due diligence efforts 
» (o İnterview personnel. 


Policies and procedures for managing third-party 
relationships need to consider the risk that each 
relationship represents, as well as how third-party 
performance and behavior will be monitored. The policy 
needs to be kepi up to date, approved by management, 
and communicated to applicable personnel. 


Due-diligence processes need to include thorough vetting 
and a risk analysis prior to establishing a formal 
relationship with the third party. Specific due-diligence 
processes and goals will vary for each entity and each is 
reguired to provide sufficient assurance that the third 
party can meet the entity's security and operational 
needs. 


A.1.5.3 Security responsibilities are defined | e Examine documentation 


clearly for each third-party engagement. e  İnterview personnel. 


The specific approach for defining security responsibilities 
will depend on the type of service, as well as the 
particular agreement between the entity and any third 
parties. The entity needs to have a clear understanding of 
ihe security responsibilities to be met by the third party 
and those to be met by the entity. 
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Security Reguiremenits Test Reguiremenis Guidance 
A.1.5.4 The entity periodically verifies that » Examineresults of periodic verification. The specific type of evidence provided by the third party 
the agreed-upon responsibilities are being e Interview personnel. will depend on the agreement in place between the two 
met. parties. The evidence needs to provide assurance that 


the agreed-upon responsibilities are being met on a 
continual basis. The freguency of verification needs to be 
aligned with the entity's risk analysis of the service being 
provided. 


PCI SSC provides from time to time guidance on best 
practice methods for management of third parties. The 
most recent guidance, including for providers of cloud- 
based services and guidance provided in the PCI DSS 
reguiremenis, should be referenced when considering this 
reguiremenit. 


A.1.5.5 Written agreements are maintained. | e (o Examine documentation. Agreements need to promote a consistent level of 
understanding between parties about their applicable 
responsibilities and be acknowledged by each party. The 
acknowledgement evidences each party's commitment to 
maintaining proper security in regard to the services. 


» (o İnterview personnel. 


i A.1.6 Educate personnel 


e Rİ RR e e e e e a a 


A.1.6.1 A security-awareness program is » (Examine documented policies and The security-awareness program needs to result in 
implemented that provides awareness to all procedures. personnel understanding the security policy and 
applicable personnel about security policy e © Examine security-awareness materials. procedures, and their responsibilities for following secure 
and procedures. processes. All personnel—including full-time, part-time, 

| and temporary employees, contractors, and consultants— 
A.1.6.2 Personnel receive security » (o Examine records of attendance. with access to or the ability to impact the security of the 


environment must be reguired to complete training. 
Training is reguired upon hire and include periodic 
refresher sessions at appropriate intervals. The freguency 
of training needs to be aligned with the entity's policies for 
education and security awareness, and commensurate 
with personnel job function. 


awareness training at defined intervals, as . 
appropriate for their job function but at least 
every 12 months. 


Interview personnel. 


A.1.6.3 Personnel are aware of the security |e Interview personnel. 
policy and responsibilities as applicable to 
their job function. 
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Security Reguiremenits | Test Reguiremenis | Guidance 


A.1.7 Screen personnel 


A.1.7.1 Personnel are screened » (Examine documented policies and The intent of screening personnel is to reduce the risk of 
(background checks) prior to being granted procedures. fraud and unscrupulous behavior from an internal 
access to the environment. e Interview personnel. resource. Role descriptions need to describe the level of 
i ) , security or access reguired for the role, and the level of 
A.1.7.2 The screening process includes » o Examine results of screening process. screening needs to be appropriate for the particular 
established criteria and a decision process position. Positions reguiring greater responsibility or that 
for background check results. have administrative access to critical data or systems 


may warrant more detailed background checks than 
positions with less responsibility and access. The policy is 
reguired to also cover internal transfers, where personnel 
in lower risk positions and who have not already 
undergone a detailed background check are promoted or 
transferred to positions of greater responsibility or access. 
The specific roles to be screened depends on the entity's 
personnel and security policies. For example, an entity 
may have a policy that reguires detailed screening for all 
personnel or defines different levels of screening for 
different job functions. 

Examples of criteria that may be appropriate include 
employmenit history, criminal records, credit history, and 
reference checks. 


A.1.8 Business as Usual (BAU) 


A.1.8.1 Review and/or monitoring is » (O Examine evidence of reviews and/or ongoing | Periodic reviews and/or ongoing monitoring of personnel 
performed periodically to confirm personnel monitoring. and activities is reguired to ensure that security İS 

are following security policies and e Interview personnel. included as part of normal business operations on an 
procedures. ongoing basis. Reviews must be performed by 


responsible personnel as defined by the entity. The 
freguency of reviews İs reguired to be defined in 
accordance with the entity's risk assessments and be 
appropriate for the particular job function. 
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Security Reguiremenis Test Reguiremenis Guidance 
A.1.8.2 Processes to detect andrespondto |e Examine documented processes. The entity needs to be able to detect any failures in 
security conirol failures are defined and e © Observe implemented processes. security controls and respond to them in a timely manner. 
implemented. , Processes for responding to security control failures is 
»e o İnterview personnel. reguired to include: 


» Restoring the security control 
» o İdentifyingtihe cause of failure 


» o İdentifying and addressing any security issues that 
arose during the failure of the security control 


» oİmplementing mitigation, such as process or technical 
controls, to prevent the cause of the failure recurring 


» (Resuming monitoring of the security control 


A.2 Secure Network Connectivity 


Security Reguirements | Test Reguiremenis | Guidance 


Conirol Objective: Network-connectivity controls provide secure pathways to the entity's systems while protecting those systems from unauthorized access 
and network-based threats. 


A.2.1 Protect systems from untrusted systems and networks 


i A.2.1.1 A security policy(s) and procedures |e Examine documented policies and Policies for protecting the environment boundaries need 
for protection of the environment boundaries procedures. to define the purpose, scope, roles, and responsibilities of 
are maintained and implemented. e Interview personnel. defined boundaries to protect system componenis from 


untrusted networks. The policy is reguired to be kept up to 
date, approved by management, and communicated to 
applicable personnel. 


A.2.1.2 Up-to-date network and data-flow » oExamine network and data-flow information. Network and data-flow information (e.g., diagrams or 
information is maintained for all e © Observe methods usedto maintain up-to- network-mapping tools) accurately document how the 
communication paths. date network and data-flow information. entity's networks are configured, the identity and location 


of all systems, how systems are connected to each other, 
and all communication paths with trusted and untrusted 
networks. 
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A.2.1.3 Access between trusted and . 
untrusted networks, systems, and ö 
applications is limited via physical and/or 
logical controls. 


Test Reguiremenis 


Examine documentation describing controls. 
Observe physical and/or logical controls. 


A.2.1.4 Traffic to and from systems is . 
restricted to only that which is necessary, 
with all other traffic specifically denied. - 


Examine documentation identifying 
necessary traffic. 


Observe configurations of ingress and egress 
conirols. 


Guidance 


Documentation illustrating authorized communications, 
both internal and external—including source and 
destination systems, interface connections, security 
conirols for those connections, and the type of data being 
seni—will assist in meeting these reguiremenis. 


Protection mechanisms may include technologies such as 
network gateways, routers, firewalls, encryption, API 
conitrols, and virtualization technigues. Controls may be a 
combination of software and hardware—e.g., use of 
packet-filtering capability based on header information, 
advanced filtering/inspection tools, and implementation of 
dedicated physical network devices or channels to 
separate network segmenis. 


Many security devices and software provide rule sets and 
settings that can validate the existence and 
methodologies used to secure network connectivity. 


A.2.1.5 Network connectivity controls are . 
monitored and/or periodically reviewed to 
confirm configurations are effective. 


Examine documented methods for monitoring 
and/or periodically reviewing network 
connectivity controls. 


Observe implemented methods and 
processes. 


Reviewing device configurations allows the entity to 
identify and remove any unneeded, outdated, or incorrect 
rules and confirm that only authorized connections, ports, 
protocols, services, and APls are allowed as defined in 
the documented business justifications. All other services, 
protocols, and ports need to remain disabled or be 
removed through periodic reviews. Review processes 
may include real-time monitoring and analysis, periodic 
maintenance cycles to ensure the conitrols are accurate 
and working as intended, and periodic reviews of network 
traffic connectivity across ports, protocols, and services. 
For guidance on services, protocols, or ports considered 
to be insecure, refer to industry standards and guidance 
(e.g., NIST, ENISA, OWASP, etc.). 
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Security Reguiremenis 


A.2.2 Protect systems from network threats 


Test Reguiremenis 


Guidance 


A.2.2.1 Controls are implemented to detect 
and/or block known and unknown network 
attacks. 


Examine documented controls/configuration 
standard. 


Observe implemented conirols. 


Controls must be implemented at the perimeter and 
critical systems points and include consideration of both 
network-based and application-based attack vectors. 
Methods of detection may include signature-based, 
behavioral, and other mechanisms that analyze traffic 
flows. Examples of tools include IDS/PS, host firewalls, 
and real-time traffic analysis tools. All mechanisms—such 
as detection engines, baselines, and signatures—must be 
configured, maintained, and updated per vendor 
instructions to ensure optimal protection. 


A.2.2.2 Suspicious traffic is blocked or 
generates an alert that is investigated and 
responded to. 


Examine documented procedures. 


Observe implemented controls and 
processes. 


If suspicious traffic is not automatically blocked, an alert 
should be generated that is actively monitored and 
immediately investigated. 


When suspicious traffic is automatically blocked, a record 
of the traffic needs to be generated and investigated to 
determine whether action is needed to preveni further 
attack. 
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A.3 Develop and Maintain Secure Systems 


Security Reguirements 


Test Reguiremenis 


Guidance 


Conirol Objective: Security risks and events can occur at any time during the lifetime of a system or application. Integrating secure processes throughout the 
lifecycle provides assurance that system integrity is maintained at all times. 


A.3.1 Secure application development 


A.3.1.1 A security policy(s) and procedures 
for secure management of the Software 
Development Lifecycle (SDLC) is 
maintained and implemented. 


Examine documented policies and 
procedures. 


Interview personnel. 


A.3.1.2 Personnel involved in software 
development are trained in secure software- 
development practices. 


Examine evidence of training. 
Interview developer personnel. 


A.3.1.3 Software development procedures 
include processes to address common 
coding vulnerabilities. 


Examine documented procedures. 
Interview developer personnel. 


A.3.1.4 Software security testing is 
conducted during the software development 
lifecycle (SDLC) using methodologies 
documented in the SDLC processes. 


Examine documented software security 
testing procedures. 


Examine results of software security 
testing. 


Interview personnel. 


A.3.1.5 The software security testing 
process identifies defects and security 
vulnerabilities. 


A.3.1.6 Identified software defects and 
security vulnerabilities are addressed prior 
to release. 


A.3.1.7 Results of software security testing 
are signed off by management prior to 
software release. 


Examine documented software security 
testing procedures. 


Examine results of software security 
testing. 


Interview personnel. 


When software is developed by the entity or bespoke or 
custom software is developed by a third party for the entity, 
ihe software-developmeni process is reguired to employ 
secure coding practices to address common vulnerabilities 
applicable to the particular technology. The entity needs to 
remain up to date with vulnerability trends and update its 
secure coding practices and developer training as needed to 
address new threats. Examples of current best practices 
include OWASP, SANS CWE Top 25, and CERT Secure 
Coding. 

Application developers must be trained properly to identify 
and resolve issues related to common coding vulnerabilities. 
Having staff knowledgeable about secure software- 
development practices minimizes the number of security 
vulnerabilities accidentaliy introduced through poor coding 
practices. Training for developers may be provided in-house 
or by third parties and needs to be appropriate for the 
technology used. 


Common methods for software security testing include threat 
modeling, code reviews, fuzz testing, and penetration testing. 
Software security testing should be performed by someone 
other than the developer of the code to allow for an 
independent, objective review. Automated tools or processes 
may also be used in ligu of manual reviews, but keep in mind 
that it may be difficult or even impossible for an automated 
tool to identify some coding errors or other security İSsues. 


Correcting identified software defects before the software is 
deployed prevenis it from exposing the environmenis to 
potential exploit. Reguiring a formal review and sign-off by 
management verifies that the software is approved and has 
been developed in accordance with policies and procedures. 
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Security Reguiremenis 


A.3.2 Configuration standards 


Test Reguiremenis 


Guidance 


A.3.2.1 A security policy(s) and procedures 
for system build and configuration 
management are maintained and 
implemented. 


Examine documented policies and 
procedures. 


Interview personnel. 


The policy document needs to explain the purpose, scope, 
roles and responsibilities, methods of access for different 
account types, configuration management, monitoring 
methodology, and controls to address known risks. 


A.3.2.2 An up-to-date inventory of all 
system componenis in the environment İS 
maintained. 


Examine system inventory. 
Interview personnel. 


Maintaining a current inventory of all system componenis 
enables an organization to accurately and efficiently apply 
security conirols to protect the assets. The inventory should 
be periodically confirmed by either manual or automated 
process—e.g., by correlation with the results of vulnerability 
scans or penetration testing—to confirm it is up to date. 


A.3.2.3 Configuration standards are defined 
and implemented for all system types. 


A.3.2.4 Configuration standards address all 
known security vulnerabilities and are based 
on industry-accepted system hardening 
standards. 


Examine system configuration standards 
and build procedures for all system 
componeni types. 


Examine system configurations. 
Interview personnel. 


A.3.2.5 Configuration standards and build 

procedures include: 

» (o Changing all vendor-supplied default 
accounis and system settings. 

» (Removing or disabling all unnecessary 
system or application functionality. 

»e (O Preventing functions that reguire 
different security levels from co-existing 
on the same system componenit. 


Examine system configuration standards 
and build procedures for all system 
component types. 


Examine system configurations. 
Interview personnel. 


System configuration standards must be kept up to date to 
ensure that newly identified weaknesses are corrected prior 
to a system being deployed in the environment. 


System configuration standards and related processes needs 
to specifically address security settings and parameters that 
have known security implications for each type of system in 
use. Examples of indusiry-accepted configuration standards 
include, but are not limited to: 

» oCenterfor internet Security (CIS) 

» o İnternational Organization for Standardization (ISO) 

» o SysAdmin Audit Network Security (SANS) Institute 

» National Institute of Standards Technology (NIST) 

The implemented controls need to provide assurance that all 
systems in the environment have known secure 
configurations. 
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Security Reguiremenits 


A.3.3 Change management 


Test Reguiremenis 


Guidance 


A.3.3.1 Change-conitrol procedures are 
defined and implemented for all changes to 
system componenis, including “emergency 
changes.” 


A.3.3.2 All changes are authorized, and the 
security impact understood prior to 
implementing the change. 


A.3.3.3 All changes are tested in a non- 
production environment. 


A.3.3.4 Rollback procedures are prepared 
for all changes. 


Examine documented change-conirol 
procedures. 


Examine records of changes and compare 
to system configurations. 


Interview personnel. 


Defined change-control procedures must be followed for any 
change that impacts systems in the environment. The impact 
of the change needs to be documented so that all affected 
parties can plan appropriately for any processing changes. 
Changes must be authorized by appropriate parties, as 
defined by the change-management policy, to verify the 
change is legitimate. 


Thorough testing is reguired to be performed to verify that the 
security of the environment is not reduced by implementing a 
change. Back-out procedures need to be documented in 
case the change fails or adversely affects the security of any 
system component. 


A.3.3.5 Unauthorized changes to system or 
application configurations are prevented 
and/or detected and addressed. 


Examine documentation of controls and/or 
processes. 


Observe implemented conirols. 
Interview personnel. 


The implemented process needs to be able to either prevent 
or detect and address the unauthorized addition, removal, or 
modification of system-critical files such as configuration file 
contents, OS programs, and application executables. If the 
implemented solution relies on detection, processes must be 
in place to ensure that unauthorized changes are detected 
and addressed as soon as possible. When unauthorized 
change attempis are automaticaliy blocked, a record of the 
attempted change should also be generated and investigated 
to determine whether action is needed to prevent further 
attempis. 


The controls could include change-detection solutions, such 
as file-integrity monitoring or a freguent re-load of a trusted 
build to restore the system component to a known secure 
state. 
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A.4 Vulnerability Management 


Security Reguirements | Test Reguiremenis | Guidance 


Control Objective: New vulnerabilities are continually being discovered and can enter the network from both internal and external sources. An ongoing cycle 
of testing and remediation helps ensure that security controls continue to be effective in a changing environment. 


A.4.1 Protect against malicious software 


A.4.1.1 A security policy(s) and procedures |e Examine documented policies and Controls must be implemented to help preveni the 
for protecting systems against malware are procedures. introduction and execution of malicious software 
maintained and implemented. e  İnterview personnel. (malware) on systems in the environment. A combination 
| of methods, tools, and programs may be used—e.g., anti- 
A.4.1.2 Controls to prevent and/or detect « © Examine documented conirols/configurations. | Malware software, application whitelisting, host-based 
and remove malicious software are e li ei and network-based intrusion-prevention tools, and system 
implemented, active, and maintained. p instrumentation. A combination of real-time protection and 
i PEene. periodic scans should be considered. 
e o Examine evidence of malware prevention The implemented controls must be kept current (e.g., 
and/or detection and removal. updated signatures, baselines, etc.) as applicable for the 
e o İnterview personnel. technology. Anti-malware controls need to remain 


enabled unless disablement is specifically authorized by 
management on a case-by-case basis for a limited time 
period. 
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Test Reguiremenis 


A.4.2 Address vulnerabilities and security weaknesses 


Guidance 


A.4.2.1 A security policy(s) and procedures 
for identifying, ranking, and protecting 
against vulnerabilities are maintained and 
implemented. 


Examine documented policies and 
procedures. 


Interview personnel. 


Policies and procedures define the methods used to 
identify and remediate vulnerabilities that could affect 


systems in the environment, and include: 
» Monitoring vulnerability lists 


» (O Performing vulnerability scans and penetration tests 


» (o Establishing bug bouniy programs 


Reputable outside sources should be used for security 


and vulnerability information. 


A.4.2.2 Vulnerability scans, both internal 
and external, are performed at least 
guarteriy to identify and address 
vulnerabilities. 


A.4.2.3 Vulnerability scans are performed 
by gualified personnel: 


External scans are performed by a PCI 
SSC Approved Scanning Vendor 
(ASV). 

Internal scans are performed by 
gualified personnel. 


Examine vulnerability scanning reports 
Interview personnel. 


Examine vulnerability scanning reporis. 
Interview personnel. 


Vulnerability scans and all reguired remediation are to be 
completed as freguently as needed to ensure 
vulnerabilities are addressed in a timely manner. Rescans 
should be performed to verify vulnerabilities have been 
addressed. In addition to a regular scanning process, 
vulnerability scans need to be performed after any 


significant change to the environment. 


Internal vulnerability scans can be performed by gualified, 
internal staff or outsourced to a gualified third party. For 
scans managed by the entity, the entity needs to ensure 
that scanning engines and vulnerability fingerprints are up 
to date and that the scanning engine is configured in 
accordance with vendor guidance documentation. 


İnternal personnel need to have sufficient knowledge to 
review and understand the scan results and determine 
appropriate remediation. Internal personnel who interact 
with an ASV or other external agency used to perform 
scanning should also be knowledgeable in the network 
architecture and implemented security controls to provide 
the ASV with information needed to complete the scan. 


i A.4.2.4 Identified vulnerabilities are ranked 
to determine the criticality of the 
vulnerability. 


Examine documented procedures for ranking 


vulnerabilities. 
Interview personnel. 


Vulnerabilities must be ranked and prioritized in 
accordance with an industry-accepted methodology or 


organizational risk-management strategy. 
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Security Reguiremenits Test Reguiremenis Guidance 
A.4.2.5 Penetration tests are performed at » Examine penetration test reporis. Penetration tests must be performed at regular intervals 
least annualiy. e — Interview personnel. and after significant changes to the environment. The 


penetration-testing methodology should be based on 
industry-accepted approaches and incorporate both 
application-layer and network-layer testing. The scope of 
testing needs to cover the perimeter and critical systems 
in the environment and include testing from both inside 
and outside the network. In addition, testing needs to be 
performed to verify that all segmentation controls are 
operational and effective, and that out-of-scope systems 
and networks do not have access to the environment. The 
specific methodology, depth, and freguency of the testing 
should be based on the entity's risk-assessmeni strategy 
and be updated as needed to consider new threats and 
vulnerabilities. 


A.4.2.6 Penetration tests are performed by » Examine penetration test reporis. Penetration testing is to be performed only by gualified 

gualified personnel. personnel who can demonstrate knowledge and 
experience, and who are organizationaliy independent of 
the environment being tested. 


» (o İnterview personnel. 


A.4.2.7 Vulnerabilities and penetration » Examineresults of penetration tests and Security patches and fixes must be implemented based 
testing findings considered as high risk are vulnerability scanning reports. on risk ranking. When high-risk vulnerabilities cannot be 
addressed within one month. All other » o Examine evidence of remediation to address | addressed within one month, a formal exception process 
vulnerabilities and identified security issues vulnerabilities and security issues. needs to be followed, including approval by personnel 


with appropriate responsibility and accountability. 


After remediation activities have been performed (e.g., 
implementing a patch or updating a configuration file to 
address a vulnerability or security flaw), rescans and 
penetration tests must be performed as necessary to 
verify the remediation is effective and that the identified 
vulnerability or security issue has been mitigated. 


A record of remediation activities should be maintained 
(e.g., via change-control records, configuration file 
updates, and audit ogs). All updates and patches must 
be managed in accordance with change-control 
processes. When applicable, changes to system 
configurations should be reflected in the configuration 
build standards. 


are addressed in a timely manner. e Interview personnel. 
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A.5 Managing Access 


Security Reguirements | Test Reguiremenis | Guidance 


Conirol Objective: Strong access conitrols protect systems and data from unauthorized access and can limit the likelihood of a compromised system being 
used to gain access to other systems and networks. 


A.5.1 Access Management 


A.5.1.1 A security policy(s) and procedures |e Examine documented policies and Policies and procedures need to include details of 

for assigning access are maintained and procedures. processes for role assignmenis, oversight processes, 

implemented. e Interview personnel. business justifications, and user and group privilege 
controls. 

A.5.1.2 Roles and responsibilities are » Examine definedroles and responsibilities. Determining who has access to what, for how long, and 

defined for groups and accounts with e — Interview personnel. what level of access they have needs to be based on 

access to systems. established roles and responsibilities. This includes the 
processes used to maintain, monitor, and approve 
administrative and user access to systems and data. 

A.5.1.3 Least privileges are assigned based | e (o Observe assigned access privileges. Access to systems and data needs to be restricted based 

on individual job function and periodicaliy e © Examine evidence that access privileges are | O business need, while also accounting for ihe sensitivity 

reviewed. periodically reviewed. of the data being stored, processed, or transmitted. 


il Access privileges must be reviewed by responsible 

»  İnterview personnel. personnel as defined by the entity. The freguency of 
reviews should be defined in accordance with the entity's 
defined policies and be appropriate for the level of 
privilege assigned. 


A.5.2 Account management 


A.5.2.1 A security policy(s) and procedures |e Examine documented policies and Established processes and oversight includes approval 

for managing accounts are maintained and procedures. process for provisioning, monitoring, changing, and 
implemented. e Interview personnel. revoking accounts with the ability to access a system. 
A.5.2.2 Individuals are assigned a unigue » (Examine documented procedures. Assigned unigue IDs are reguired to allow the i 
account ID. organization to maintain individual responsibility for 


»e (o Observe account settings. 


actions and an effective audit trail per employee. 
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A.5.2.3 Controls are implemented to protect 
the confidentiality and integrity of accounts 
and credentials. 


Test Reguiremenis 


Examine documented procedures. 
Observe implemented conirols. 


Guidance 


Implemented controls need to protect the confidentiality 
and integrity of accounts for both local and remote users. 
The controls are reguired to include ensuring that account 
and credential information is securely transmitted and 
stored (e.g., using strong cryptography) at all times. 


A.5.2.4 Controls are implemented to prevent 
misuse Of accounis. 


Examine documented procedures. 
Observe implemented controls. 


Processes to prevent misuse of accounts needs to 
include, at a minimum, the use of account lockouts, 
lockout durations, session timeouts, and reactivation 
processes. İnactive user accounts must be removed or 
disabled within a timely manner. All processes need to 
align with the entity's security policies and procedures. 


A.5.2.5 Access for third parties is identified, 
controlled, and monitored. 


Examine documented procedures. 
Observe implemented controls. 


Configuration and connection reguirements must be 
defined and implemented for all access by third-party 
personnel. For example, ensuring accounts are enabled 
only during the time needed and disabled when not in 
use, and monitoring account activity when in use. 


A.5.2.6 Access privileges are monitored 
and/or reviewed at least guarterly by an 
authorized individual to confirm access is 
still reguired. 


Examine documented processes. 


Examine evidence of monitoring and/or 
reviews. 


Interview personnel. 


All access privileges must be reviewed regularly, at least 
guarteriy, by an authorized individual. Documentation of 
reviews needs to be retained. Results of these reviews 
need to include identification and removal of any 
unneeded or incorrect access, and to ensure that only 
individuals with a current business need are granted 
remote access. 


Automated processes may be used to assist in reviewing 
access privileges (e.g., to generate notifications when an 
account has not been used for a period of time). 
Organizational processes to actively review and change 
access when an individual changes job function can also 
assist. 
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Security Reguiremenits | Test Reguiremenis | Guidance 
A.5.3 Authentication 


A.5.3.1 All access to systems reguires » (Examine documented procedures. Authentication consists of one or more of: 


strong authentication prior to access being » (o Observeimplemented controls. »e o Something you know, such as a password or 
granted. passphrase 


» Something you have, such as a token device or smart 
card 


» Something you are, such as a biomeiric 


When passwords are used, documented reguiremenis 
need to include considerations for entropy 
(strength/complexity), password history and reuse, reset 
processes, and other best practices for secure password 
use. Passwords need to meet a minimum level of 
strength, as defined by the entity's security policy, that 
provides reasonable assurance they are not guessable 
and would withstand a brute-force attack. 
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A.5.3.2 Multi-factor authentication is 
reguired for all access to systems in the 
environment. 


Test Reguiremenis 


Examine documented procedures. 
Observe implemented controls. 


Guidance 


Multi-factor authentication (MFA) reguires the completion 
of at least two different authentication methods (that İS, 
something you know, something you have, and 
something you are) prior to access being granted. The 
authentication mechanisms used need to be implemented 
to ensure their independence such that: 


» o Accesstoonefactor does not grant access to any 
other factor, and 


» The compromise of any one factor does not affect the 
integrity or confidentiality of any other factor. 


Additionally, no prior knowledge of the success or failure 
of any factor can be provided to the individual until all 
factors have been presented. Refer to industry standards 
and best practices for further guidance on MFA principles. 


MFA can be applied at the network level, system level, or 
application level. For example, MFA could be applied 
when connecting to the secure network or network 
segmeni, or when connecting to an individual system 
component in the environment. 


MFA is reguired for all personnel connections to the 
systems in the environment that occur over a network 
interface. Examples of access include for purposes of 
maintenance, configuration, updating, administration, or 
general management of the systems or networks. MFA is 
not reguired for application or system accounits 
performing automated functions. 
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A.6 Physical Security 


Security Reguirements 


Test Reguiremenis 


Guidance 


Conirol Objective: Individuals with physical access to systems or media could potentially bypass logical access conirols and gain access to sensitive assets. 
Strong physical access conitrols also protect against the unauthorized addition, modification, removal, or damage of systems and data. 


A.6.1 Resirict physical access 


A.6.1.1 A security policy(s) and procedures 
for securing physical access to systems İs 
maintained and implemented. 


Examine documented policies and 
procedures. 


Interview personnel. 


A.6.1.2 Facility entry controls are in place to 
limit and monitor physical access to systems 
in the environment. 


Observe physical access conirols. 


A.6.1.3 Physical access for personnel to the 
environment is authorized and based on 
individual job function. 


Examine assigned access permissions. 
Interview personnel. 
Observe personnel access procedures. 


A.6.1.4 Personnel access is revoked 
immediately upon termination, and all 
physical access mechanisms, such as keys, 
access cards, etc., are returned or disabled. 


Examine documented procedures. 


Examine evidence of access revocation and 
return of physical access mechanisms. 


Interview personnel. 


The entity needs to define the physical access controls 
reguired to prevent systems from being accessed 
physically by unauthorized persons. The controls need to 
cover all physical access points and include procedures 
for managing onsite employees and third parties. Specific 
procedures are reguired for managing visitors, including a 
visible means for identification and escorts by authorized 
personnel. 


Physical access and monitoring controls need to include 
use of video cameras and/or access-control mechanisms. 
Data from video cameras and/or access-control 
mechanisms needs to be logged to provide an audit trail 
of all physical access to the environment. Access logs 
must be retained in accordance with the entity's audit log 
policy. (Refer to Reguirement A.7.2.) Monitoring and 
periodic reviews of physical access controls and audit 
logs need to be performed to allow early identification of 
incorrect controls and for timely response tO SUSpİCİOUS 
activities. Personnel are reguired to be trained to follow 
procedures at all times. 


All suspicious activity needs to be managed per incident 
security procedures. (Refer to Reguirement A.7.1.) 


A.6.2 Secure media 


A.6.2.1 Sirict control is maintained over the 
storage and accessibility of media. 


Observe implemented conirols. 
Interview personnel. 


Controls and processes need to cover secure storage, 
transport, and disposal of all storage media used in the 
environment. Procedures and technical controls are 
needed to provide assurance that media cannot be 
removed, stolen, or copied by unauthorized persons. The 
specific controls and level of rigor reguired to protect 
media must be appropriate for the sensitivity of the data 
stored on the media. 
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Security Reguirements | 


Conirol Objective: An effective incideni-response plan allows an entity to respond to potential security issues guickly and effectively, and minimize the 


Incident Response Preparedness 


Test Reguiremenis 


potential impact of a security incident or breach. 


Guidance 


A.7.1 Incident-response plan 


A.7.1.1 A security policy(s) and procedures 
for managing and responding to security 
incidents is maintained and implemented. 


» (Examine documented policies and 


procedures. 


» o İnterview personnel. 


The policy needs to define plans, procedures, and 


technologies to detect, analyze, and promptly respond to 
security incidents. Defined procedures need to include 
response activities, escalation, and notification, and cover 


all assets and processes that could impact critical 
operations or data. Procedures must be updated in 


alignment with operational/business changes and the 


organization's risk strategy. 


A.7.1.2 An incident-response plan is in 
place that includes: 


» Roles andresponsibilities 
» Communication and contact sirategies 
» o Specific incident response procedures 


» Businessrecovery and continuity 
procedures 


» Data back-up processes 


» (Analysis oflegalreguiremenis for 
reporting compromises 

» (oCoverageandresponses ofall critical 
system components 


» (o Consideration of payment brands” 
response reguiremenits 


» (Examine documented incidenit-response 


plans and procedures. 


» o İnterview personnel. 


The incident-response plan needs to be comprehensive 
and include coverage of all systems in the environment. 


At a minimum, communication and contact strategies 


need to include notification of the payment brands. 


Incident response personnel/teams must be trained and 
knowledgeable in incident-response procedures and be 


available to respond immediately to an incident. 


A.7.1.3 The plan is reviewed and tested at 
least annualiy. 


» (Examine documented procedures. 


» (Examine evidence of reviews and testing. 


» o İnterview personnel. 


The incident-response plan needs to be reviewed, tested, 
and updated periodically to incorporate lessons learned. 
Relevant staff must be included in the testing and be 
briefed on the post-test review. Testing needs to include 
validation that system, audit, and monitoring logs are 


available and contain all needed data. 
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Security Reguiremenis 
A.7.2 Audit Logs 


Test Reguiremenis 


Guidance 


A.7.2.1 A security policy(s) and procedures 
for generating and managing audit logs is 
maintained and implemented. 


» (Examine documented policies and 
procedures. 


» (o İnterview personnel. 


The policy needs to cover reguiremenis for the 
generation, collection, management, and retention of 
audit logs for all system components in the environment. 


A.7.2.2 Audit logs are implemented to: 


» linkallaccessto systemstoan 
individual user. 


» (Record security evenis. 


» oExamine system configurations. 
»e (O Observe access attempis. 
» Examineauditlogfiles. 


Recording all personnel access, both physical and logical, 
to systems in the environment is reguired to help the 
entity identify any misuse of accounits and ensure that 
each individual is accountable for their actions. 


The determination of “security event” will vary for each 
organization and may include consideration for the type of 
technology, location, and function of the system. Logging 
of security events needs to include notifications or alerts 
related to suspicious or anomalous activities (e.g., as 
defined in Reguirements A.2.2.2 and A.3.3.5). The level 
of detail logged is reguired to be sufficient to identify who, 
what, where, when, and how an event occurred in the 
environment. 


A.7.2.3 Time synchronization is 
implemented on systems to ensure system 
clocks are synchronized and have the 
correct and consistent time. 


» (Examine system configurations. 


Designated central time server(s) must be defined to 
receive time signals from trusted external sources based 
on İnternational Atomic Time or UTC. Ceniral time 
server(s) should peer with one another to keep accurate 
time. Systems receive time only from designated central 
time server(s). 

Time-synchronization technology needs to be kepi current 
and time data must be protected from unauthorized 
modification. 


A.7.2.4 Logs and security events are 
monitored and/or reviewed periodically for 
all systems to identify anomalies or 
SuSpİCİOUS activity. 


» Examine evidence of reviews of logs and 
security evenis. 


»e o İnterview personnel. 


Real-time monitoring and/or periodic reviews need to be 
in place for all security events, critical system logs, and 
security system logs (e.g., firewalis, IDS/PS, 
authentication servers, e-commerce redirection servers, 
etc.). The freguency of reviews should align with the 
associated risk. 

The use of log harvesting, parsing, and alerting tools can 
help facilitate the process by identifying log events that 
must be reviewed. 
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Security Reguiremenits 


A.7.2.5 Audit logs are secured so they 
cannot be altered. 


Test Reguiremenis 


Examine controls/configurations. 
Observe attempits to modify audit logs 


Guidance 


Only individuals who have a job-related need should be 
able to view audit log files. Audit logs should be backed 
up promptly to a cenitralized log server or media that is 
difficult to alter. Physical and logical access controls must 
be in place to prevent unauthorized modifications to audit 
logs. File-integrity monitoring or change-detection 
software can be implemented to ensure that any changes 
to saved log data generate an alert. 


A.7.2.6 Audit and monitoring logs are 
retained for least one year, with a minimum 
of three months immediately available for 
analysis. 


Examine audit log files. 
Interview personnel. 


Log-retention policies need to include storage and 
retrieval procedures. If stored in off-line locations, 
procedures need to include assurance that log data can 
be retrieved in a timely manner. The logs to be retained 
include at least those defined in Reguirement A.7.2.2. 
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AppendixB Attack Costing Framework 


This appendix provides the framework for cost calculation of attacks on the MPoC Solution and/or its componenis. 


It starts with the description of differences between hardware- and software-based tamper-responsive systems, followed by guidelines that 
must be considered for an attack cost calculation framework. The considerations include the importance of the attack scalability factor as well 
as its definition, remediation and pre-remediation solutions, and their role and construction of a full attack path. The full attack path rating is 
consitructed based on the tests conducted during the evaluation as per testing reguiremenis. 


The rating process is described by listing the steps that the laboratory performs when rating a full attack based on the information collected by 
partial attack tests and documentation analysis. 


The relevant factors that this costing framework takes into account include attack time, attacker expertise, scalability, knowledge of A&M back- 
end systems, eguipmenit reguired for the attack, and COTS device access. The detailed description of all the factors is followed by a 
discussion about ratings, with examples that show the importance of different factors. 


Differences between Hardware and Software Tampering 


There are differences between a hardware-based tamper-responsive system and a software-based tamper-responsive system that are 
considered as we look at the attack-costing framework. The key differences are: 


4. Physical presence and scalability. A hardware-based tamper-responsive system generally reguires an attacker to be physically 
present, while a software-based tamper-responsive system could be vulnerable to remote attacks. Additionally, the exploitation phase of 
attacks on software-based tamper-responsive systems could reguire much less time, expertise, and tools, increasing the scalability of 
the attack even if the attack reguires physical presence. 


5. Layered security. Like hardware tamper-response systems, software tamper-response systems are based on layered security; however, 
tihe number of layers and relevance of each level are much more prominent for software tamper-response systems. This means that 
multiple levels of protection must be bypassed before an attacker can extract an asset. Therefore, full and partial attacks must be 
considered as well as remediation technigues. Additionally, the detection approach of a tamper state is much more disiributed in nature. 
For example, a tamper state might be detected by the back-end attestation and monitoring system with support of the MPoC Application. 


6. Technology. There are much wider sets of technologies that contribute to the layered security in the case of software-based tamper- 
responsive systems, such as software-based protection in REE, TEE solutions partially supported by hardware, and SE solutions. 
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7. Useof COTS and attack stages: The use of numerous supporting technologies in a layered security architecture leads to a full attack 
necessarily consisting of several stages. The following stages are considered: 


a. Gaining control of the COTS device (rooting). Gaining control of the platform either by using an OEM supported method or based 
on existing exploits is often the first stage of an attack. While it is often the first stage, it could be that the MPoC Application itself has 
an exploitable vulnerability and that full control of the COTS is not needed for the full attack path. Prevention of remote attacks on 
platforms includes regularly updating the COTS OS. 


b. Gaining control of the MPoC Application. Even for a COTS device under full attacker control, several security mechanisms have to 
be circumvented to gain control of the MPoC Application. Gaining control of the MPoC Application is usualiy the second stage of the 
attack. It might be possible to access some of the assets by controlling only the COTS device (COTS-native NFC data, touch signals); 
however, there might be additional security mechanisms added by the MPoC Application, in which case control of the MPoC 
Application is needed. 


c. Assetcompromise. Asset compromise is the goal of the attack and usualiy attainable after the second stage of the attack. It could be 
possible that after getting access to ihe COTS, the assets of ihe MPoC Application could be extracted from memory without 
necessarily gaining full control of the MPoC Application. However, the MPoC Application could protect against these attack paths. 


Gaining control of the COTS device or device rooting refers to obtaining the necessary privileged level of control on the COTS device for a 
particular attack. Currently, rooting or jail-breaking is possible in multiple COTS platforms. Therefore, merchants as well as merchant 
employees could enable root access to a COTS Platform on which an MPoC Application is running. 


Remote exploits to gain root access for the most common COTS device types are available for non-patched versions of those COTS 
platforms. Remote exploits to gain access to updated versions of platforms would reguire development of zero-day exploit. The effort reguired 
for such activity would reguire a significant amount of work. 


The proactive attestation of the platform is the key aspeci of the security protection against the attacks that reguire rooting. Attestation of the 
platform that relays on hardware mechanisms within the platform (e.g., TEE, Secure processors) usualiy provide a significant barrier for an 
attacker. 


For attacks that reguire root privileges, rooting is considered a first step of a full attack, and the estimated effort for identification and 
exploitation are accounted for based on public knowledge. If sufficiently resistant anti-root mechanisms are present or rooting of the COTS 
device is not possible for other reasons, the full attack cannot be executed. 
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Considerations for Attack Cost Calculations 


The following considerations exist for this attack framework: 


" o İdentification and exploitation stages 
" oScalability rating factor 

" o Remediation and pre-remediation 

" oPartial andfull attacks 


Identification and Exploitation Stages 


For an attacker wanting to exploit a vulnerability, the vulnerability must first be identified. This may appear to be a irivial separation, but it 
is an important one. To illustrate this, first consider a vulnerability that is uncovered following months of analysis by an expert, anda 
simple attack method published on the Internet. Compare this to a vulnerability that is well known but reguires enormous expenditure of 
time and resources to exploit. Of course, factors such as time need to be treated differently in these cases, and therefore the “cost” 
reguired to identify an exploit is included in the costing calculation. 


Exploitation involves the actual performance of an attack (partial or full) on a live system. 


Scalability Rating Factor 


This factor addresses the attack potential that affectis large groups of merchanis that use the same MPoC Application. 


While an attack can be remote, local attacks following a few simple pre-described steps could lead to a scalable attack. Even if physical 
access İs necessary for an effective pre-described attack, the fraud could be performed on multiple merchant COTS devices by an 
organized group of attackers or merchant employees downloading the attack description from the internet. 


Scalability of an attack could depend on the control of the COTS device (usually referred to as “rooting”) if that step is reguired for the 
full attack. In some cases, rooting can be achieved by the phone owner; however, anti-rooting mechanisms and attestation functions 
supported by the hardware of different COTS could create a significant obstacle to scaling such an attack. 


Control of the COTS device with highest privileges could also be obtained by exploiting the COTS platform remotely. This can potentially 
lead to scalable attacks for partial attacks that depend on the rooting of the COTS. The only way to prevent such scalable attacks is to 
have a sufficiently patched system for all approved COTS devices. 


As the evaluation laboratory assesses only one version of the MPoC Application, the portability of the attack cannot be assessed on the 
level of the MPoC Application. 


Scalability of the attack is of high importance for MPoC Solutions, as reflected in the number of points given to the scalability factor. 
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Remediation and Pre-remediation 


Remediation provides the MPoC vendor with a solution for attacks against which the MPoC Application cannot defend in the field and 
renders the solutions sufficiently secure. The remediation step is possible only after successful detection of some portion of an attack, 
such as changes to the security configuration of the COTS platform, but prior to the exploitation of those changes to expose any asseis. 


In case of pre-remediation, the product is updated on a regular basis to implement proactive mitigations against known attack paths, or 
so that the learning curve for the execution of an attack is reset at every update — thereby necessitating a new identification phase for 
any known attacks. Pre-remediation may resolve the attack attempits that cannot be detected by A&M back-end systems or prevent 
those attacks that are already known. 


Remediation and pre-remediation are not rated, but they determine whether a partial attack is feasible. If an attack reguires more time 
than the pre-remediation cycle takes, or if the attack can be detected and mitigated before the fraud is performed, the partial attack is 
not considered when constructing the full attack. 


Approach to Attack Calculations 


Where the MPoC standard reguires a costing be provided as evidence for a testing reguiremenit, the costing is to be provided for the 
specific asset or context of the reguirement. For example, a test reguirement may reguire that a cryptographic key be exposed by the 
attack, and another may reguire that a PIN be exposed. Each of these attacks are to be considered independently and without 
consideration for any other assets. An attack that reguires that a PIN be exposed is considered successtful even if the attack does not 
also expose the cardholder data associated with that PIN. 


When considering an attack, the laboratory may look to chain multiple “partial” attacks — each one used to bypass a specific security 
control — which can be then chained into a “full” attack that is used to compromise the specific asset covered by the test reguirement 
under assessment. 


Partial attacks provide the lab with a possibility to assess strengths of different security measures toward the full attack (i.e., a partial 
attack is to tesit-specific security mechanism(s), and a full attack is to compromise a specific assets). It provides the vendor with the 
analysis of which security measures in the chain are the weakest. Circumventing one countermeasure while having five working 
together toward a secure produci is not a significant increase of risk. Circumventing four out of six reduces the security level significantly 
and increases the risk toward a full attack. 


" oPartial and full attacks. When the lab assesses a partial attack, the rating factors should be noted to have a clear view for the full 
attack (combination of multiple partial attacks). After assessing the strength of all security protection features, the laboratory 
needs to analyze the possibility of a full attack. For a possible full attack, the laboratory will calculate the rating based on the 
factors determined for all partial attacks as described in the next section. 


" oRemediation and pre-remediation. Remediation and pre-remediation can be used to disgualify a partial attack from 
consideration for rating. The tester, however, has to perform the attack to assess the time needed for the attack development. The 
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attack can be disgualified if the pre-remediation and remediation technigues act faster than the time needed for identification and 
exploitation. The learning curve from the previous attacks or laboratory expertise must be taken into consideration. 


Rating Procedure 


The security landscape in which MPoC systems operate dictates a risk-mitigation approach toward the dynamically developing risk landscape. 
In short, if the security robusiness can be circumvented by a skilled attacker de-layering the security architecture, the MPoC Solution could 
remediate the risk-pre-remediation and remediation technigues discussed in the previous section) and keep the security level sufficientiy high. 


The rating approach, which takes into account the attestation and monitoring detection time as well as the remediation time before the costing 
for a full attack is considered, is shnown in Figure 4. The laboratory needs to collect sufficient evidence that attack detection and remediation 
together are sufficiently strong to prevent an attack, including attacks that use knowledge from any previous attack attempts. Where the 
laboratory finds that a partial attack is possible, that is some part of the security controls can be bypassed, the laboratory may choose to 
expose this in their reporting so that the vendor may consider if steps can be taken to improve these security controls. 
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Figure 4: Attack Costing Rating Procedure for a Full Attack 


An attack costing is needed 


The tester performs testing 
to validate security measures 


The tester performs and/or 
validates the most feasible 
attack 


Does the 
attack 
compromise 
the relevant 
assets? 


Can A&M 
detect attack 
prior to 
completion? 


Can multiple 
partial attacks 
be chained to 
do this? 


Can A&M 
prevent attack 
completion? 


YES 


YES An attack costing is 
produced 


No attack costing is 
produced. Other attacks 
should be considered 


Where the A&M is not explicitly reguired to be disabled by the test reguirement, consideration is needed with respect to the ability of the A&M 
to detect and remediate the full attack before it is completed. If testing indicates that the full attack fails because it is detected and successfuliy 
remediated prior to the compromise of any assets, then that is not to be considered as a successlul attack and no rating is to be given to that 
attack. In such cases, the laboratory is expected to consider additional or alternative attack paths that would not be detected and remediated. 


If the partial attack that circumvenis the security protection mechanism cannot be detected and remediated or pre-remediated, the attack can 
contribute to the full attack path. Therefore, it is necessary to identify the values that different rating factors have so that a full attack rating can 
be calculated. A full attack comprised of partial attacks without remediation or pre-remediation should be rated. The rating of full attacks based 


on testing of security componenis is described below. 
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If a full attack cannot be constructed, but there are several successtful partial attacks, the remaining risk should be identified by the laboratory. 
Because the security is built from layers of protection measures, the fact that some of the measures can be circumvented reduces the overalI 
security of the solution. Therefore, the remaining risk for the solution should be described. 


The relevant factors for attack rating are shown in the following table. 
Table 6: Attack Rating Table 


Attack Factor Identification Exploitation 


Attack time 


Attacker Expertise 


Scalability 


Knowledge back-end systems 


Eguipment 


COTS device access 


Subtotal 


Total 


As shown in Figure 4, partial attacks factors are assessed after the tester performs relevant tests. Partial attacks are analyzed and the tester 
determines whether a composition could lead to a full attack. For a possible full attack, the laboratory will calculate the rating based on the 
factors determined for all partial attacks with the following approach: 


" oAttacktime: Ihe time taken for that stage of the attack (identification or exploitation) to be completed. 


" oAttacker Expertise: The partial attack with the highest expertise determines the expertise of the full attack. The full attack would 
not be possible without all the partial attacks and expertise needed for them. 


" o Knowledge back-end systems: If the knowledge of the back-end systems is needed for any of the partial attacks, the rating of 
the full attack is determined by the highest level of knowledge needed. The full attack would not be possible without all the partial 
attacks. 


" o Eguipment: The partial attack with the most complex eguipment determines the eguipment of the full attack. The full attack would 
not be possible without all the partial attacks and eguipment needed for them. 
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« oOCOTS device access: The partial attack with the most difficult category of the COTS device access determines the COTS device 
access of the full attack. The full attack would not be possible without all the partial attacks and needed COTS device access for 
each of them. 


" oScalability: The scalability of the attack is determined based on all the partial attacks that have to be executed. If a step cannot 
scale easily to a simple and effective attack, the full attack is not scalable. 


The categories are rated with values as described in the rest of this section. 


Attack Time 


The attack time is given in the time in hours taken by an attacker to identify or exploit an attack. If the attack consists of several steps, 
the attack time can be determined and added to achieve a total attack time for each of these steps. Actual labor time must be used 
instead of time expired as long as there is not a minimum attack time enforced by the attack method applied (for instance, the time 
needed for performing a side-channel analysis, data collections, or the time needed for an epoxy to harden). 


In those cases where attendance is not reguired during part of the attack time, the attack time is to be taken as expired time divided by 


3. 
Attack Time | Identification | Exploitation 
<1 Day 2 2 
<1 week 3 3 
<1 month 5 5 
>1 month 7 7 
Attacker Expertise 


The attacker expertise factor determines the needed expertise to perform the attack identification and exploitation. The identified levels 
of expertise are as follows: 


" oLayman. Persons without professional or specialized knowledge in a particular subject. An attacker who is capable of using an 
exploit in the form of a script or a written procedure prepared by another attacker. Laymen could be capable of minimal 
modifications dictated by a simple step process. A layman may be capable of developing an attack if it involves the use of existing 
platform features (e.g., activating a screen recorder function provided by the OS). 


" oProficient. Persons who are competent and have the necessary ability, knowledge, and skill to perform customization of attacks 
successtuliy. They are familiar with the security functionalities and behavior of the underlying systems. Proficient attackers are 
capable of flashing OS images and can use root access and management software such as Magisk. 
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" Expert. Persons who are highiy knowledgeable and skillful in one or more areas. They are familiar and knowledgeable regarding 
needed aspecis of the solution that could include the underiying OS, algorithms, protocols, hardware components, and physical 
and logical architectures implemented in the COTS device or system type. This person is capable of developing or introducing 
complex modifications of an exploit for a specific vulnerability in the system. 


Attacker 
Expertise Identification Exploitation 
Layman 0 0 
Proficient 3 3 
Expert 4 4 


Scalability 


While the time and expertise reguired to identify and exploit a vulnerability are similar for both hardware and software tamper-responsive 
systems, it should be noted that a software attack can be re-used much easier on the same or different platforms, even if the local 
presence is reguired to initiate the exploitation. 


Along with the attack specifics, the following categories are identified: 


Scalability Identification Exploitation 
Instance Specific N/A 18 
Scalable with NA 6 
physical access 
Remotely scalable N/A 0 
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Instance specific: The attack is not scalable and needs to be heavily customized for each COTS device (e.g., the attack 
depends on the extraction of keys from each COTS device, and that extraction process must be performed as a bespoke process 
for each COTS device attacked). 


Scalable with physical access: The attack can be leveraged against multiple COTS Platforms and/or MPoC Application 
instances, but reguires that the attacker has physical access to the COTS device during the attack. Consideration for if locked or 
unlocked access is necessary is calculated in the “access” part of the costing. 


Remotely scalable: The attack may be leveraged against multiple COTS Platforms and/or MPoC Application instances, and does 
not reguire the attacker to have any physical access to the COTS device during the attack. Scalability of the attack is of a very 
high importance for the MPoC; therefore, it has a high number of points. 


Scalability scoring only applies to the exploitation phase of the attack, and a costing that is instance-specific is mostly likely to also 
reguire proficient or expert skill during the exploitation stage of the attack (as expertise is reguired to be used during the attack to 
enable its application on the instance under attack). 


An MPoC assessment must consider the types of COTS Platforms to which the MPoC Application may be deployed, but it is not 
possible to make determinations during the assessment of how many specific COTS Platforms may be included in any given MPoC 
Solution. For this reason, the scalability factor is given as two types — scalable (with or without physical access), or instance specific. If 
an attack is scalable across any given subset of tihe COTS Platforms supported, it must be considered a scalable attack. 


While attacks can be remote, local attacks following a few simple pre-described steps can lead to fraud performed on multiple merchant 
COTS devices by an organized group of attackers or by merchant employees downloading the description from the internet. Such 
attacks must also be considered scalable. This type of attack would be costed as “Scalable with physical access.” 


A scalable attack may also be performed remotely by fooling a merchant into clicking links or installing malicious application and 
providing the needed privileges to that application. This would be costed as “Remotely scalable.” 


Scalability of an attack could depend on the control of the COTS device (rooted device) if that step is reguired for the full attack. 
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Knowledge of the A&M Back-end Systems 


The back-end attestation and monitoring (A&M) is a critical component of the overall software tamper-responsive system. This 
component is especially critical in a software-based payment, where depending on security and risk management policies, the 
monitoring system may terminate the paymeni transaction capability of any MPoC Application instance immediately when there are 
signs that the COTS device may be compromised. The knowledge of the attestation and monitoring (A&M) can be critical for performing 
certain attacks. It includes information on its capabilities and behavior, possibiy including the anomaly detection algorithms used to 
interpret the various attestation data that comes from the MPoC Application. Identified levels are as follows: 


Knowledge of 


A&M Identification Exploitation 
Public information 0 0 
Restricted 1 1 
information 
Sensitive information 3 4 


" o Public information about the back-end monitoring system (or no information): Information is considered public if it can be easily 
obtained by anyone (e.g., from the Internet) or if it is provided by the vendor to any customer. 


" oORestricted information concerning the back-end monitoring system (e.g., as gained from vendor technical specifications): 
Information is considered restricted if it is distributed on reguest and the distribution is registered. 


" o Sensitive information about the back-end monitoring system—e.g., knowledge of internal design, which may have to be 
obtained by “social engineering” or exhaustive reverse-engineering. 
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Eguipment 
Attackers may reguire the use of eguipmeni in the execution of some attack vectors. The type of eguipmeni reguired to execute an 
attack vector will determine the attack cost associated. The two levels are: 


" o Standard SW/only includes pre-existing tools which can be easily obtained, such as Frida, Magisk, or jail-breaking scripts and 
procedures. 


" oSpecializedeguipmeni includes special software that is not readily available and has to be created. 


Eguipment Identification Exploitation 
Standard SW/only 0 0 
Specialized 3 3 


The COTS device security, including the acceptability of any hardware used in the MPoC Solution, is the responsibility of the MPoC 
Solution provider and their risk management system. Hardware-based security relies on the fact that such solutions have passed high 
assurance security assessmenis. The risk management system as well as methods used to determine the acceptability of any hardware 
security level is assessed by the MPoC laboratory with the documentation assessment based on the relevant security certification as 
listed in the reguiremenis of this document. Therefore, hardware attacks themselves and hardware eguipmeni used for such attacks are 
Out of scope of this rating system. 


COTS Device Access and Remote Attacks 


While some attack vectors reguire only remote access to the COTS device, other attack vectors reguire local levels of COTS device 
access. This attack cost factor considers attack vectors that reguire varying degrees of access to the physical COTS device under 
attack. 


Remote attacks for fully patched platforms are rare and reguire significant effort and skills. Unpatched systems as well as possible zero- 
day vulnerabilities could facilitate remote attacks. Zero-day vulnerabilities that provide remote access to the platform are difficult to find 
for the whole community, let alone for a laboratory during the time of the evaluation. Such attack chains are either very difficult to find 
and reguire a lot of time or the expertise to develop attack chains is not readily available. 


The unpatched systems have vulnerabilities that are publicly available and it is the responsibility of the evaluation laboratory to assess 
the effort of implementing the exploit depending on the type of vulnerabilities as shown in the example ratings within this section. Use or 
support of unpatched systems can be expected to lead to reduced time, expertise, or increased scalability for an attack — potentialiy 
reducing attack ratings to an unacceptable level. 
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The assessment should consider recently disclosed vulnerabilities, which may lead to potential attacks. It is a reguirement of this 
standard that the A&M systems are constantly updated to monitor for and/or address vulnerabilities that could affect the security of the 
payment process. 


Three types of access are identified: 

" ORemote— where no physical access is reguired. 

" oLocallocked— where physical access is reguired, but the device may be in a locked state. 
" o Local unlocked— where physical access with the device in an unlocked state is reguired. 


Access Identification Exploitation 
Remote 0 0 
Local locked 0 2 
Local unlocked 0 3 


Attacks that are marked as “scalable with physical access” will always reguire local access in the costing as well. 
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Summary Attack Rating Table 


The table below summarizes the factors and costings for an MPoC attack rating. 


Attack Time Identification Exploitation 
<1 Day 2 2 
<1 week 3 3 
<1 month 5 5 
>1 month 7 7 
Attacker Expertise Identification Exploitation 
Layman 0 0 
Proficient 3 3 
Expert 4 4 
Scalability | Identification Exploitation 
Instance Specific N/A 12 
Scalable with physical N/A 6 
access 
Remotely scalable N/A (0) 
Knowledge of A&M Identification Exploitation 
Public information 0 0 
Restricted information 1 1 
Sensitive information 3 4 
Eguipment Identification Exploitation 
Standard SW/only (0) (0) 
Specialized 3 3 
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Access Identification Exploitation 
Remote 0 0 
Local locked 0 2 
Local unlocked 0 3 


Discussion of Ratings with Examples 


In this section, we present the theoretical attacks of different types and considerations. The attack costing examples show how the 
assessment of an MPoC Product may differ based on the strength, scalability, and modality (local/remote) of the attack. These costings are 
provided as examples only and are not necessarily indicative of all costing possibilities for solutions that meet the high-level criteria provided. 


The examples provided include the following types of MPoC Solutions: 
" o Arelatively weak MPoC Solution with a scalable attack and one that prevents a scalable attack. 
" oArelatively strong MPoC Solution with a scalable attack and non-scalable attack. 


« An MPoC Solution where there is the ability to use legitimate functionality provided by the COTS OS to expose account data, in 
both remote and non-remote attack modes. 
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Example of a Weak Solution 


An example of a weak solution has the following evaluation results: 


Lack of obfuscation. 


Weak attestation functions (bypass possible). 


The relevant parameters of this attack if it were scalable are: 


Attack Factor Identification Exploitation 

Attack time < 1 week 3 < 1 day 2 
Attacker Expertise Proficient 3 Layman 0 
Scalability N/A 0 Scalable 0 
Knowledge back-end systems Public information 0 Public information 0 
Eguipment Standard 0 Standard 0 
COTS device access Local unlocked 0 Remote 0 
Sub total 2 
Total 


Successful dynamic binary instrumentation (reguiring rooted COTS device), which leads to payment assets disclosure. 


Available remote exploit for several approved platforms as well as possibility for merchant and merchant employee to root the 
COTS device without being detected by the backend. 
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The relevant parameters of this attack if some aspeci prevenits scalability are: 


Attack Factor Identification Exploitation 

Attack time < 1 week 3 < 1 day 2 
Attacker Expertise Proficient 3 Proficient 3 
Scalability N/A (0) Instance specific 12 
Knowledge back-end systems Public information 0 Public information 0 
Eguipment Standard 0 Standard 0 
COTS device access Local unlocked 0 Remote 0 
Sub total 17 
Total 23 
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Example of a Sirong Solution - Scalable and non-Scalable Examples 


An example of a strong solution has the following evaluation results: 


It takes an expert 2-3 weeks or more to reverse engineer the solution and circumvent the runtime security mechanisms. 


Obfuscation is very good. 


Rooting is not detected (or rooting detections can be easily circumvented). 


The relevant parameters of this attack (for a scalable solution) are: 


Attack Factor Identification Exploitation 
Attack time < 1 month 5 < 1 day 2 
Attacker Expertise Expert 4 Layman 0 
Scalability N/A 0 Scalable 0 
0 0 


Knowledge back-end systems 


Public information 


Public information 


Eguipment Specialized 3 Standard 0 
COTS device access Local unlocked 0) Remote 0 
Sub total 12 2 
Total 14 
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If this attack was instead not scalable (due to MPoC Solution controls, or simply the type of vulnerability exploited) the costing would 
instead be as below: 


Attack Factor Identification Exploitation 

Attack time < 1 month 5 < 1 day 2 
Attacker Expertise Expert 4 Proficient 3 
Scalability N/A (0) Instance specific 12 
Knowledge back-end systems Public information 0 Public information 0 
Eguipment Specialized 3 Standard 0 
COTS device access Local unlocked 0 Remote 0 
Sub total 12 17 
Total 29 


Use and Abuse of Legitimate Functionality Provided by OS 


Different attacks exist that use legitimate functionality provided by the OS to gain access to MPoC assets. Examples of such attacks 
include TeaBot, Cloak, or Dagger using an overlay function as well as accessibility services or developer controls. This example 
including rating indicates how laboratories should approach such risks during the evaluation. 


An example of an abuse of legitimate functionality attack has the following evaluation results: 


Merchant security-guidance documents (user guidance) do not prevent merchant, employees, or attackers from installing a 
malicious application to monitor touch events, turn on developer options, give the malicious application logging privileges, and run 
applications in the background. 


The attestation and monitoring mechanism does not provide sufficient information about: 
— The applications that can monitor touch evenis. 

— Whether the developer options are turned on. 

— Whether malicious applications are running in the background. 

The attack is scalable either in the sense that: 


— Anyone can access and perform these actions on the COTS that runs the application, deeming this attack scalable in the 
sense of simplified activities that can be performed on multiple sites. 
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The relevant parameters of this attack are: 


— The attack can be performed remotely by fooling a merchant into installing malicious application and providing the needed 
privileges. 


Attack Factor Identification Exploitation 

Attack time < 1 month 5 < 1 day 2 
Attacker Expertise Proficient 3 Layman 0 
Scalability N/A 0 Scalable 0 
Knowledge back-end Public information 0 Public information 0 
systems 
Eguipment Standard 0 Standard 0 
COTS device access Local unlocked 0 Local unlocked 3 
Sub total 8 5 
Total 13 
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If this attack reguired the attacker to be physically present to attach a cable and execute a simple set of commands on a locally 
unlocked device, the costing would instead be as below: 


Attack Factor Identification Exploitation 
Attack time < 1 month 5 < 1 day 2 
Attacker Expertise Proficient 3 Layman 0 
Scalability N/A (0) Scalable with physical access 6 
Knowledge back-end Public information 0 Public information 0 
systems 
Eguipment Standard 0 Standard 0 
COTS device access Local unlocked 0 Local unlocked 3 
Sub total 8 11 
Total 19 


If instead the attack reguires more advanced expertise and tooling to expose, and more skill to perform on each device (but still with 
local unlocked access), the costing would instead be: 


Attack Factor Identification Exploitation 
Attack time < 1 month 5 < 1 day 2 
Attacker Expertise Expert 4 Proficient 3 
Scalability N/A 0 Scalable with physical access 6 
Knowledge back-end Public information 0 Public information 0 
systems 
Eguipment Specialized 3 Standard 0 
COTS device access Local unlocked 0 Local unlocked 3 
Sub total 12 14 
Total 26 
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Detailed Examples 


This section provides rating examples for two attacks to support the laboratory in rating full attack paths based on its assessment of solution 
componenis and construction of the full attack from there. Although rating of a full attack on a platform cannot be tested within the scope of the 
MPoC evolution, the attack shows the effort needed, as well as the rating that such an attack would receive. Managing risks of attacks on the 
COTS platforms is handled by the MPoC Solution vendor risk-managemenit system as assessed with this program. The second example is 
based on testing activities within the scope of this program. 


Example of Attack on a Platform - Full Attack - Remote Attack on Platform 


Note: The attack activities are out of scope for testing activities within MPoC evaluation process 


The first example describes the attack on the platform that cannot be identified during the MPoC Application assessment by the 
laboratory. Nevertheless, this attack is included to provide insight into the effort needed for such attacks and show the rating approach. 
The risk of the remote attacks on the platform should be addressed by the MPoC Solution provider process that manages risks. 


The full attack described here could lead to payment assets disclosure by gaining full control of the platform and assuming the MPoC 
Application is weak and trusts the COTS platform. The attack is based on the real-world attack presented by Samuel Gro (©5aelo), 
Project Zero in Full remote attack based on No Clicks Reguired - Exploiting Memory Corruption Vulnerabilities in Messenger Apps. 


This attack describes what is reguired to gain remote access and privilege escalation on a platform without known vulnerabilities. The 
attack description is publiciy available. 


Attack description: The steps of the attack are: 


1. Reverse engineering: A researcher starts with the exploration of the MPoC Application structure and protection measures. 
Sometimes this knowledge is ported from the community. After extracting the contents of the MPoC Application and exploring it, the 
researcher finds a vulnerability in the NSUnarchiver API that can be triggered without interaction via iMessage, which includes a 
Shared key dictionary. The vulnerability is registered as CVE-2019-8641 and it is a type of confusion attack. 


2. Understanding platform protection: The researcher analyzed the solution to identify attack countermeasures. The first 
countermeasure included separating data and execution parts of the memory and preventing writing in execution parts. However, it 
would be possible to use existing functions and build return-oriented programming by storing pointers to functions instead. To prevent 
this attack path, the mitigation technigues of ASLR, Pointer Authentication (PAC), and Code signing have been introduced. The ASLR 
or address space layout randomization is a countermeasure to prevent return-oriented programming and prevent jumping to 
predefined addresses. Pointer authentication is present to prevent return-oriented programming. It uses a tag in a pointer to sign and 
verify pointers. 
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3. Buildingan exploit: To exploit the vulnerability, the researcher must overcome ASLR as well as PAC. ASLR is overcome by 
heap spraying with pointers and PAC is handled by creating fake instances of legitimate classes. At this point, the researcher has 
access to data and camera, and can run code outside the sandbox. 


4. Privilege escalation: The next step is “borrowed” from another researcher (published exploit) and consists of expanding the 
existing attack with the kernel exploit SockPuppet (CVE-2019-8605 from JavaScript), which has not been patched. This stage of the 
attack provides access to platform hardware, FS, disabling of code signing, hiding malware, etc. 


5. Conclusion: At the final stage, the attacker has full control over the platform. For a MPoC Application in the COTS device that 
suffers such a breach, the paymeni assets could be available in memory or by developing additional code to tailor the attack to access 
ihe COTS-native NFC and send the card data to a remote server. 


Comments and rating process. Discovering the parts of this attack, as some parts have been borrowed from other experts, took about 
1-t0-2 people approximately 3 months. Despite the long identification time, the scalability of the attack indicates it is a lucrative pursuit 
for attackers. Because the attack is available publicly, if the MPoC Application would support a vulnerable platform, it would be weak 
against memory dumping and instrumentation, and the A&M would not detect the version and prevent the MPoC Application from 
working. As a result, the tester would have to rate the attack. 


Attack Factor | Identification | Exploitation 
Attack time > 1 month 7 < 1 day 2 
Attacker Expertise Expert 4 Layman 0 
Scalability N/A (0) Scalable 0 
Knowledge back-end Public information 0 Public information 0 
systems 
Eguipment Specialized 3 Specialized 3 
COTS device access Local unlocked 0 Remote 0 
Sub total 14 5 
Total 19 


This attack reguires the highest level of expertise, consumes significant amounis of time, and results in high scalability on a subset of 
platforms. This has the potential of affecting significant number of merchants and driving the rating below acceptable levels. 


If the A&M system implemented robust controls to prevent this type of attack, it is possible that “sensitive information” would be reguired 
in the identification phase (43 points) as well as proficient skill in the exploitation phase (43 points) to facilitate bypassing of the A&M 
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controls. Alternatively, new zero-day type attacks may reguire specialized eguipment in terms of the attack software. Therefore, different 
implementations and attack scenarios may result in similar attacks producing an overall costing of 25 points or above. 


Example - Full Attack - Perform Fake Paymenis 


This attack describes what is reguired to perform faked paymenis for a specific MPoC Application with several security measures that 
have been shown to provide limited resistance during laboratory testing. 


Attack description. An attacker with MPoC Application control can modify the MPoC Application to simulate payments when the 
attacker card is detected. The attacker can acguire goods at the attacked merchant and the screen of the COTS device being used will 
behave normally, displaying the expected information on the screen; however, it will not send the paymeni to the backend. A merchant 
with enough transactions per day will probabiy identify the theft as shoplifting, as it lsaves no trace in the system. 


The steps of the attack are: 


6. Rooting the COTS device. Older Android versions can run the MPoC Application based on the policy of the MPoC Solution. 
Therefore, the rooting of a COTS device can be performed with standard tooling by unlocking the bootloader and installing a public 
rootkit. The attestation system does not deteci this partial attack. 


The relevant parameters of this partial attack are: 
— Elapsedtime: <1 day 

— Attacker Expertise: Laymen 

— Scalability: scalable 

— Knowledge of A&M backend: NA 

— Eguipment: Standard software 

— COTS device access: local locked 


7. Running an MPocC Application on a rooted COTS device. It is possible to run the MPoC Application on a rooted COTS device 
as anti-instrumentation. Anti-debugging can be circumvented due to the following weakness found during the evaluation: 


a. Circumventing runtime protection. It was identified that runtime protection is limited to some parts of the code, leaving 
the possibility for the attacker to modify the unprotected code flow relevant for this attack. 
b. Sensitive information is logged. The current state of the execution flow of the MPoC Application reveals information 


such as messages from security componenis and the current state of the execution flow. This information can aid in attacking the 
MPoC Application flow. 


c. Monitoring system. It is possible to circumvent the anti-instrumentation because no information is sent to the backend 
about the MPoC Application being compromised. It is possible to perform the transaction after the Frida instrumentation script was 
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ported. The back-end system does not show any reactions caused by the compromise of the MPoC Application or COTS device. 
User-specific information was not removed from the phone due to the compromise. 


The relevant parameters of this partial attack are: 
— Elapsedtime: <İ week 

— Attacker Expertise: Proficient 

— Scalability: scalable 

— Knowledge of A&M backend: NA 

— Eguipment: Standard software 

— COTS device access: local locked 


8. Developing exploit. Because the obfuscation and run-time integrity are found to be weak during the evaluation, the development 
of an exploit that modifies the code flow could be performed. 


Circumventing the obfuscation and developing the exploit would reguire the following parameters: 
— Elapsedtime: >1 week 

— Attacker Expertise: Expert 

— Scalability: scalable 

— Knowledge of A&M backend: NA 

— Eguipment: Standard software 

— COTS device access: local locked 


Therefore, the full attack would have the following rating: 
— The elapsedtime for identification is accumulated for all the steps resulting in the attack time below a month. 


— The elapsed time for exploitation considers only the activities that must be repeated for other COTS devices with the same 
platform <1 day. 


— Forall other categories, the highest necessary rating is considered because it is the minimum for the full attack to be 
completed. For example, if one partial attack reguires expert while the rest of the partial attacks reguire only proficient, the full 
attack cannot be completed without an expert. 


— For exploitation, only the activities that must be repeated are considered in the rating. 
The steps of the attack are costed in a full attack table below: 
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Attack Factor Identification Exploitation 
Attack time < 1 month 5 < 1 day 2 
Attacker Expertise Expert 4 Layman 0 
Scalability N/A 0 Scalable with physical access | 6 
Knowledge back-end Public information 0 Public information 0 
systems 
Eguipment Standard 0 Standard 0 
COTS device access Local unlocked 0 Local locked 2 
Sub total 10 
Total 19 
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Appendix C Minimum and Eguivalent Key Sizes and Strengths for Approved 
Algorithms 


Table 7 lists the minimum key sizes and parameters for the algorithms used with key transport, exchange, or establishment and for data 
protection in connection with these reguirements. Approved key establishment schemes are described in NIST SP800-56A (ECC/FCC3-based 
key agreemeni), NIST SP800-56B (IFC-based key agreemenit) and NIST SP800-38F (AES-based key encryption/wrapping). 


Other key sizes and algorithms may be supported for non-paymenit brand relevant transactions; otherwise, these are the only encryption 
algoritams designated as Approved Algorithms. 


Table 7: Minimum Key Size 


Algorithm IFC (RSA) ECC (ECDSA, ECDH, ECMGV) | FFC(DSA, DH, MOV) 


Minimum key size in number of bits 2048 224 2048/224 128 


Eguivalent Key Sizes 


Key-enciphermeni keys are to be at least of egual or greater strength than any key they protect. This applies to any key-enciphermenit keys 
used to protect secret or private keys that are stored, keys used to encrypt any secret, or private keys for loading or transport. For purposes of 
this reguiremeni, the algoritams and key sizes in each row are considered eguivalent. In Table 8: 


" ORSA keysizerefersto the size of the modulus. 


« o Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve. This order is to be slightly smaller than 
the field size. 


" DSA keysizesrefer to the size of the modulus and the minimum size of a large subgroup. 
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Table 8: Eguivalent Key Sizes 


Algorithm Effective Bit IFC (RSA) ECC (ECDSA, ECDH, FFC (DSA, DH, MOV) 
Strength ECMOV) 
Minimum key size in number of bits 112 2048 224 2048/224 — 
Minimum key size in number of bits 128 3072 256 3072/256 128 
Minimum key size in number of bits 192 7680 384 7680/384 192 
Minimum key size in number of bits 256 15360 512 15360/512 256 


For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH): 


" O DHimplementations entities must generate and distribute the system-wide parameters securely: generator g, prime number p and 
parameter a, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long and parameter g must be at least 224 
bits long. Each entity must generate a private key x and a public key y using the domain parameters (p, g, 9). 


" OECDH implementations entities must securely generate and distribute the system-wide parameters. Entitiles may generate the 
elliptic curve domain parameters or use a recommended curve (see FIPS186-4). The elliptic curve specified by the domain 
parameters must at least be as secure as P-224. Each entity must generate a private key d and a public key O using the specified 
elliptic curve domain parameters. (See FIPS 186-4 for methods of generating d and O.) 


" oEach private keyis to be statistically unigue, unpredictable, and created using an approved Random Number Generator (RNG), 
as described in this document. See Table 10for more information. 


" oEntitiesare to authenticate the DH or ECDH public keys using DSA, ECDSA, a certificate, or a symmetric MAC (see /SO 16609 — 
Banking —Reguiremenis for message authentication using symmetric technigues). Öne of the following should be used: 
— MAC algorithm 1 using padding method 3 
— MAC algorithm 5 using padding method 4 
TLS implementations are used to prevent using cipher suites that do not enforce the use of cryptographic ciphers, hash functions, and key 
lengths as outlined in this appendix. 


KCVS are values used to identify a key without revealing any bits of the actual key itself. Some check values are computed by encrypting an 
ali-zero block using the key or component as the encryption key by using the leftmost n-bits of the result, where n is 24 bits (10 hexadecimal 
digits or 5 bytes) for AES. Alternatively, AES uses a technigue where the KCV is calculated by MACing an ali-zero block using the CMAC 
algorithm as specified in ISO 97971 (see also NIST SP 800-38B). The check value will be the leftmost n-bits of the result, where n is 10 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0— Appendix C November 2022 
© 2022 PCI Security Standards Council, LLC. All rights reserved. Page 216 


» Security Li 
Standards Council 


hexadecimal digits. AES is the block cipher used in the CMAC function. The key length of a key or component will be MAC'd using the AES 
block cipher with an eguivalent lengih (e.g., AES-128 uses 128-bit for MAC while AES-256 uses 256). 


Hash Algorithms 
For hash algorithms used for authentication or security purposes, only the algorithms and associated bit lengths in Table 9 are permitted. 
Table 9: Hash Algorithms 


Algorithm Length 


SHA? family >255 


SHA3 family >255 


RNGs are either a deterministic random number generator or a Non-deterministic Random Number Generator (NRNG). 


Random Number Generators 


All DRNG must be seeded by an NRNG that provides sufficient authenticated entropy. The entropy reguired must be at least as many bits as 
the intended key strength and should be twice as many bits. Entropy sources are discussed in NIST SP800-90B. 


Table 10: Random Number Generators 


RNG Reguirement 
DRNG Tested and approved under NIST SP 800-90A or ISO/IEC 18031 ($9| 
NRNG Tested and approved under NIST SP 800-90C or ISO/IEC 18031 ($8| 


Prime Number Generators 


For cryptographic processes that reguire prime numbers, use prime number generators tested to ISO/IEC 18032 Information Technology-- 
Security Technigues: Prime Number Generation or X9.80 Prime Number Generation, Primality Testing, and Primality Certificate. 
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AppendixD Secure Software Lifecycle Reguirements 


This appendix provides a baseline of security reguirements with corresponding assessment procedures and guidance to help software 
vendors that design, develop, and maintain secure software used in the solution throughout the software lifecycle. Vendor's commitment to 
building capability to develop and maintain secure software is demonstrated by either: 


" o Evaluation per Appendix D by an approved MPoC Laboratory as part of its evaluation, or 


« o Through an independent assessmeni of software lifecycle management practices assessed by a Secure SLC Assessment 
performed by a Secure SLC Assessor (listed on the PCI SSC website) and confirmed by submitting a Secure SLC ROC and 
Secure SLC AOC. 


Leveraging PCI Secure SLC Standard for Appendix D Security Reguirements 


The SSF Secure SLC Standard defines security reguiremenis for paymenit-software vendors to integrate security throughout the entire 
software lifecycle, resulting in software that is secure by design and better able to withstand attacks. Software vendors whose development 
processes have been validated as meeting the Secure SLC Standard are listed on the PCI SSC website as a Secure SLC Oualified Vendor. 


It is possible to validate compliance to the security reguiremenis in this appendix by confirming that the following are met: 


" The softwarelifecycle management practices were assessed by a Secure SLC Assessor and confirmed to meet all reguirements 
in the Secure SLC Standard with the results documented in a Secure SLC ROC and Secure SLC AOC. 


" The software was developed and is being maintained using the software lifecycle management practices that were covered by the 
Secure SLC assessmenit. 


«  Afull Secure SLC assessment of the software lifecycle management practices was completed within the previous 36 months. 
Additionally, if the most recent full Secure SLC assessment occurred more than 12 months ago, an Annual attestation was 


provided by the developer/vendor within the previous 12 months that confirms continued adherence to Secure SLC Standard for 
ihe software lifecycle management practices in use. 
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D.1 


Software Security Governance 


A formal software security governance program is established to reflect the vendor's commitmenit to build secure software, and protect any 
sensitive assets and resources stored, processed, or transmitted by that software. 


Security Reguiremenis 


D.1.1 Security Responsibility and Resources 


Test Reguiremenis 


Guidance 


Senior leadership team establishes formal responsibility and authority for the security of the vendor's products and services, and resources are allocated to 
execute the strategy and ensure that personnel are appropriately skilled 


D.1.1.1 Overall responsibility for the 

security of the vendor's products and 
services İs assigned by the vendor's 

senior leadership team. 


D.1.1.1.a Examine vendor evidence and interview the 
individual or individuals assigned overall 
responsibility for the security of the vendor's products 
and services to confirm the following: 


Accountability for ensuring the security of the 
vendor's products and services is formaliy 
assigned to an individual or team by the vendor's 
senior leadership. 


Responsibilities include keeping senior 
leadership informed of security updates, issues, 
and other matters related to the security of the 
vendor's products and services. 


Updates are provided to senior leadership at 
least annually on the performance of and 
changes to the vendor's software security policy 
and strategy described in Control Objective 2. 


The formal assignment of responsibility by the vendor's 
senior leadership team ensures strategic-level visibility into 


and influence over the vendor's software security 


practices. Senior leadership typically represents those 
individuals or teams with the responsibility and authority to 


make sitrategic business decisions for the vendor 


organization. In many cases, senior leadership teams are 
comprised of members of the executive team such as the 
chief executive officer (CEO), chief financial officer (CFO), 
chief technology officer (CTO), chief information officer 
(CIO), chief risk officer (CRO), or similar roles, but this is 


not true for all organizations. Ultimately, the distinct 


structure of the senior leadership team is determined by 


the vendor. 


Assignment of overall responsibility for the vendor's 


software security program should include the authority to 
enforce and execute the organization's software-security 
strategy. Without appropriate authority, those responsible 
for the security of the vendor's products and services 
cannot be reasonabiy held accountable for ensuring that 
the organization's security strategy İs followed. Those 
responsible for the vendor's software security should 
provide periodic updates on the state of the vendor's 
software security program and the performance of its 
strategy to senior leadership. This allows senior leadership 


to make sure the strategy is being prioritized and 


resourced properiy, and that changes reguired as a result 


of its performance are approved in a timely manner. 


(continued on next page) 
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Security Reguiremenis Test Reguiremenis Guidance 


Evidence to support this control objective might include 
job descriptions, organization charts, presentations, audio 
recordings, senior leadership meeting minutes, reporits, e- 
mails, formal communications from senior leadership to 
ihe rest of the organization, or any other records that 
clearly reflect formal assignment of responsibility and 
authority, and communications between senior leadership 
and those responsible for the vendor's software security 
program regarding program performance. 


D.1.1.2 Software security responsibilities D.1.1.2.a Examine vendor evidence to confirm the Individuals, including third-party personnel, involved in the 
are assigned. following: design, developmeni, testing, and maintenance of the 
vendor's products and services should be assigned 
responsibility and accountability for ensuring that software 
i : is designed and maintained in accordance with the 

ii e software-development vendor's security strategy and all applicable security 

i reguiremenis, including software-specific reguiremenis. 

» o Assignmentofresponsibilities for ensuring tihe (| Responsibilities can be assigned to an individual, group, 
security of the vendor's products and services or role; however, individuals assigned to a particular 


» o Software security responsibilities are clearly 
defined and assigned to appropriate individuals 


covers the entire software lifecycle. group or role should clearly understand how those 
i software security responsibilities affect their individual job 
D.1.1.2.b Interview a sample of responsible functions, the organization's security expectations, and 
individuals, including software-development the individual's role in fulfilling those expectations. 
personnel, to confirm they are clearly aware of and Individuals assigned software-security responsibilities 
understand their software security responsibilities. should be able to demonstrate an understanding of their 


responsibilities and accountability. 


Evidence to support this security objective might include 
job descriptions, employee agreemenis, presentations, 
company communications, training materials, e-mails, 
intranet content, or any other documentation or records 
that clearly and consistentily show the assignmenit of 
security responsibilities, and the acknowledgement and 
understanding of those roles and responsibilities. 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0— Appendix D November 2022 
© 2022 PCI Security Standards Council, LLC. All rights reserved. Page 220 


> Security Li 
Standards Council 


Security Reguiremenis 


D.1.1.3 Software-development personnel 
maintain skills in software security matters 
relevant to their specific role, 
responsibility, and job function. 


Test Reguiremenis 


D.1.1.3.a Examine vendor evidence to confirm the 
following: 


A mature process is implemented and 
maintained for managing and maintaining 
software security skills for software- 
development personnel. 


The skills reguired for each defined role, 
responsibility, and job function are clearly 
defined. 


The criteria for maintaining individual skills are 
clearly defined. 


The process includes a review at least annualiy 
to ensure software-development personnel are 
maintaining the necessary skills for the security 
responsibilities they have been assigned. 


D.1.1.3.b For a sample of software-development 
personnel, examine vendor evidence and interview 
personnel to confirm the following: 


Individuals have demonstrated that they 
possess the skills reguired for their role, 
responsibility, or job function. 


Individuals have satisfied the criteria for 
maintaining their individual skills. 


Guidance 


To be effective in meeting their software security 
responsibilities, software-development personnel must be 
trained or have experience in performing such 
responsibilities and must maintain the appropriate skills to 
properiy carry out those responsibilities. 


At a minimum, all software-development personnel must 
have a basic understanding of general software security 
concepis and best practices. Individuals with specialized 
roles and responsibilities should additionally possess 
specialized skills relevant to the functions they perform. 
Examples of specialized skills include secure software 
design (software architects), secure coding technigues 
(software developers), and security-testing technigues 
(software testers). 


Efforts to maintain those skills may include vendor- 
provided training, ongoing participation in local or regional 
user groups, or the achievement and maintenance of 
industry-specific certifications. It is up to the vendor to 
define the necessary criteria for maintaining appropriate 
job-specific skills and confirm individual adherence at 
least annualiy. 


Evidence to support this security objective might include 
policies and processes, training materials or content, 
records of on-the-job training or course attendance, 
individual gualification certificates, continuing education 
credits, or any other documentation or evidence that 
demonsirates clearly and consistently that software- 
development personnel possess and maintain appropriate 
skills and knowledge for their specific job function and 
responsibilities. 
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Security Reguiremenis 


D.1.2 Security Responsibility and Resources 


Senior leadership team establishes formal responsibility and authority for the security of the vendor's products and services, and resources are allocated to 
execute the strategy and ensure that personnel are appropriately skilled 


Test Reguiremenis 


Guidance 


D.1.2.1 Regulatory and industry security 
and compliance reguirements applicable 
to the vendor's operations, products, and 
services and the data stored, processed, 
or transmitted by the vendor are identified 
and monitored. 


D.1.2.1 Examine vendor evidence and interview 
personnel to confirm the following: 


A mature process exists to identify and monitor 
external regulatory and industry security and 
compliance reguiremenis. 


The process includes reviewing sources of 
regulatory and industry security and compliance 
reguiremenis for changes at least annualIy. 


The process results in an inventory of external 
regulatory and industry security and compliance 
reguiremenis. 


The inventory is updated as external security 
and compliance reguirements change. 


Many organizations are subject to reguiremenis for 
protecting certain types of information and data such as 
personally identifiable information (PII), cardholder data 
(CHD), and protected health information (PH). 


Vendors should maintain awareness of evolving industry 
and regulatory reguiremenis applicable to their operations 
and products. Maintaining ongoing awareness of external 
security and compliance obligations allows the vendor to 
ensure its processes adeguately address those 
reguiremenis at all times, including whenever those 
reguiremenis are updated, or new reguiremenis 
introduced. 


Evidence to support this control objective might include 
documented policies and processes, internal standards, 
reguirement mappinggs, internal presentations, training 
materials, or any other documentation or records that 
clearly and consistentiy show that the vendor has made 
reasonable efforts to understand and monitor its external 
security and compliance reguiremenis. 
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Security Reguiremenis 


D.1.2.2 A software security policy is 
defined and establishes the specific rules 
and goals for ensuring the vendor's 
products and services are designed, 
developed, and maintained to be secure, 
resistant to attack, and in a way that 
satisfies the vendor's security and 
compliance obligations. 


Test Reguiremenis 


D.1.2.2.a Examine vendor evidence to confirm the 
following: 


A software security policy exists and is 
communicated to appropriate vendor personnel 
and business partners, including all software- 
development personnel. 


At a minimum, the policy covers all control 
objectives within this standard either explicitly or 
implicitly. 

The policy is defined in sufficient detail such 
that the security rules and goals are 
measurable. 


The vendor's senior leadership team has 
approved the software security policy. 


D.1.2.2.b Interview a sample of software- 
development personnel to confirm they are aware of 
and understand the software security policy. 


Guidance 


Vendors must establish a company-wide software 
security policy to ensure that all individuals or teams - 
including relevant business partners - involved in software 
design, development, and maintenance are aware and 
have a consistent understanding of how the vendor's 
software products and services should be securely built 
and maintained, and how any critical assets should be 
handled. The software security policy (or policies) should 
be known and thoroughiy understood by those with the 
responsibility to ensure they are met, as well as those 
individuals and teams who have the ability to affect the 
security of the vendor's products and services. The 
vendor's senior leadership team should openiy support 
the establishment and enforcement of the security policy 
through appropriate communications to vendor personnel, 
to reinforce the importance of software security to the 
vendor organization and its leadership. 
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Security Reguiremenis 


D.1.2.3 A formal software-security 
strategy for ensuring the security of the 
vendor's products and services and 
satisfying its software security policy is 
established and maintained. 


Test Reguiremenis 


D.1.2.3.a Examine vendor evidence and interview 
responsible personnel to confirm the following: 


» Astrategyto ensurethe security of the vendor's 
products and services is defined. 


» The software-security strategy clearly outlines 
how the software security policy is to be 
satisfied. 


» The software-security strategy is based on or 
aligned with industry-accepted methodologies. 


» The software-security strategy covers the entire 
lifecycle of the vendor's products and services. 


» The software-security strategy is communicated 
to appropriate personnel, including software- 
development personnel. 


» The software-security strategy İs reviewed at 
least annually and updated as needed, such as 
when business needs, external drivers, and 
products and services evolve. 


D.1.2.3.b Interview a sample of software- 
development personnel to confirm they are aware of 
and understand the software-security strategy. 


Guidance 


A software-security strategy is a high-level plan, roadmap, 
or methodology for ensuring the secure design, 
development, and maintenance of the vendor's products 
and services, and adherence to the vendor's software 
security policy. 


Vendors should either adopt existing frameworks or 
methodologies or develop their own in accordance with 
industry-accepted practices for secure software lifecycle 
management. By aligning its software-security strategy 
with industry-accepted methodologies, the vendor is less 
likely to overlook important aspects of secure software 
lifecycle management. 


Vendors that develop their own methodologies should 
understand how they differ from indusiry-accepted 
methodologies, identify any gaps, and ensure that 
sufficient evidence is maintained to clearly show how their 
methodologies are at least as effective as those accepted 
by the industry. Examples of indusitry-accepted 
methodologies that are commonly used as benchmarks 
for secure software development and management 
include, but are not limited to, current versions of: 


» (SEC 27034 Application Security Guidelines 
» Building Security In Maturity Model (BSIMM) 


» (OWASP Software Assurance Maturity Model 
(OpenSAMM) 


» NIST Special Publication 800-160 and its Appendixes 


The software-security strategy should evolve as internal 
factors, such as the vendor's business strategy or 
product/service offerings or external factors such as 
external security and compliance reguiremenis, evolve. 
Therefore, the software-security strategy is not static and 
should be reviewed and updated periodically to maintain 
alignment with business needs and priorities. 


(continued on next page) 
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Security Reguiremenis Test Reguiremenis Guidance 


Evidence to support this reguirement might include 
documented security plans or methodologies, 
presentations, policies and processes, training materials, 
meeting minutes, interviewer notes, e-mails or executive 
communications, mappings, or references to industry- 
accepted methodologies, gap analysis results, or any 
other records or documentation that clearly and 
consistently shows that the vendor has made a 
reasonable effort to develop, maintain, and keep current a 
formal strategy for satisfying the vendor's software 
security policy. 
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D.1.2.4 Software security-assurance 
processes are implemented and 
maintained throughout the entire software 
lifecycle. 


Note: The focus is on the overall 
managemeni of securily-assurance 
processes and provides the foundation for 
specific assurance processes defined 
within this document. 


Test Reguiremenis 
D.1.2.4.a Examine vendor evidence and interview 
personnel to confirm the following: 


» o Software security-assurance processes are 
defined, implemented, and maintained. 


» o Aninventory of software security-assurance 
processes is maintained. 


D.1.2.4.b For a sample of software security- 
assurance processes, examine vendor evidence 
and interview personnel to confirm the following: 


» o Software security-assurance processes clearly 
address the specific rules and goals within the 
vendor's software security policy. 


» o Software security-assurance processes are 
aligned with the vendor's software-security 
strategy. 


» (O Vendor personnel, including software- 
development personnel, are assigned 
responsibility and accountability for the 
execution and performance of the security- 
assurance process in accordance with D.1.1.2. 


» oTheindividuals or teams responsible for 
performing and maintaining each security- 
assurance process are clearly aware of their 
responsibilities. 


» oTheresults or outcomes of each security- 
assurance process are monitored in 
accordance with D1.2.6. 


Guidance 


Software security-assurance processes are activities that 
are implemented to carry out the vendor's software- 
security strategy and to facilitate secure software design, 
development, and maintenance. To ensure that security 
and compliance reguirements are met, software security 
policy is satisfied, and the vendor's products and services 
are secure and resistant to attack, vendors need to define 
such processes throughout all phases of the software 
lifecycle. These may include security “checkpoints,” which 
are distinct points within the software-development 
process where software is checked to make sure security 
reguiremenis are met. Examples of software security- 
assurance processes and controls include software- 
design reviews, automated code reviews, security-specific 
functional testing, and change-managemenit processes. 
For organizations that leverage Agile software- 
development methodologies, security checkpoints may be 
incorporated into the “story” acceptance criteria or the 
criteria for determining when work is considered “done.” 


Evidence to support this reguirement might include 
documented policies and processes, security-control 
inventories, output from Governance Risk and 
Compliance (GRG) or other management tools, software- 
specific reguirements documentation, or any other 
evidence that clearly and consistently identifies the 
software security-assurance processes that have been 
implemented and shows that the security-assurance 
processes are appropriate for the function they are 
intended to provide. Additionally, evidence to show the 
software security-assurance processes are implemented 
properly may include system or process outputs such as 
threat models, security test results, bug tracking data, 
audit log data, incident response, etc. 
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Security Reguiremenis 


D.1.2.5 Evidence is generated and 
maintained to demonstrate the 
effectiveness of software security- 
assurance processes. 


Test Reguiremenis 


D.1.2.5.a Examine vendor evidence, including the 
inventory of software security-assurance processes, 
and interview personnel to confirm that evidence is 
generated and maintained for each security- 
assurance process. 


D.1.2.5.b For a sample of security-assurance 
processes, examine evidence and other output from 
the processes and interview personnel to confirm 
the evidence generated for each process 
reasonably demonstrates the process is operating 
effectively and as intended. 


Guidance 


To demonstrate the effectiveness of software security- 
assurance processes, evidence should be generated and 
maintained for each process to show that it directiy results 
in or contributes to the expected security outcomes (€.g,., 
fewer vulnerabilities or greater resistance to attacks). 


Evidence needs to be freguently collected and kept up to 
date to ensure it accurately reflects the ongoing 
effectiveness of security-assurance processes. Without a 
track record of performance for software security- 
assurance processes, it becomes almost impossible to 
effectively perform root-cause analysis when such 
processes fail to produce the expected results. 


Evidence to support this objective might include security 
control and evidence generation inventories, vulnerability 
reports, penetration testing results, or any other records 
and evidence that clearly and consistently shows 
evidence is generated for each software security- 
assurance process and that the evidence clearly shows 
the effectiveness of the processes. 
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D.1.2.6 Failures or weaknesses in 
software security-assurance processes 
are detected. Weak or ineffective security- 
assurance processes are updated, 
augmented, or replaced. 


Test Reguiremenis 


D.1.2.6.a Examine vendor evidence and interview 
personnel to confirm the following: 


» A mature process existsto deteci and evaluate 
weak or ineffective security-assurance 
processes. 


» Thecriteriafor determininga weak or 
ineffective security-assurance process are 
defined and justified. 


»e (o Security assurance processes are updated, 
augmented, or replaced when deemed weak or 
ineffective. 


D.1.2.6.b For a sample of the security-assurance 
processes identified in D.1.2.4, interview personnel 
and examine any additional evidence necessary to 
determine if any failures or weaknesses in those 
security processes occurred, and to confirm that 
weak or ineffective processes were updated, 
augmented, or replaced. 


Guidance 


Software vendors should monitor their security-assurance 
processes to confirm the processes remain appropriate 
(i.e. fit for purpose), and effective for their intended 
purpose and function. For example, the use of manual 
code reviews may be sufficient to deteci all coding errors 
and vulnerabilities for software with a very limited code 
base. However, as the code base grows, the use of 
manual code reviews for the same purpose becomes 
increasingiy impractical or insufficient, and automated 
testing tools (such as automated static-code scanners 
and dynamic software-analysis tools) should be used. 


One method for detecting weak or ineffective security 
controls is to define a set of metrics or trends that can be 
used to measure the effectiveness of security-assurance 
processes. For example, the results from a vendor's 
security testing may provide greater insight into the 
effectiveness of security-assurance processes. İf security 
tesis repeatediy find vulnerabilities within the software, it 
may indicate that applicable security-assurance 
processes are not being executed properly or working as 
intended. Another method for detecting weak or 
ineffective security-assurance processes would be to 
perform regular reviews of those processes and the 
evidence generated by those processes to verify they 
continue to be appropriate for their intended purpose. 


Evidence to support this reguirement might include 
process-generated evidence, security test results, root- 
cause analysis, documented remediation actions, or any 
other evidence that clearly and consistentiy shows that 
the effectiveness of software security-assurance 
processes is monitored, failures and weaknesses are 
detected, and security-assurance processes are updated, 
augmented, or replaced when no longer effective at 
satisfying their intended purpose. 
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D.2 Secure Software Engineering 
Software is designed and developed to protect critical software assets and to be resistant to attacks. 


Security Reguiremenits | Test Reguiremenis | Guidance 


D.2.1 Threat Identification and Mitigation 
Continuously identifies, assesses, and manages risk to its software and services. 


D.2.1.1 Critical assets are identified and D.2.1.1.a Examine vendor evidence to confirm the | Before the vendor can determine how to effectively 
classified. following: secure and defend its software against attacks, it must 
first develop a thorough understanding of the software's 

critical assets that could be targeted by attackers. 


Critical assets include any sensitive assets collected, 
stored, processed, or transmitted by the vendor's 
software, as well as any sensitive functions and sensitive 
resources within or used by the software. Examples of 
analysis technigues that could be used to identify critical 


» Amatureprocessexisisto identify and 
classify critical assets. 


» Thecriteriafor identifying critical assets and 
determining the confidentiality, integrity, and 
resiliency reguiremenis for each critical 
assets are defined. 


»* oThe process accounis for all types of critical assets include, but are not limited to, Mission Impact 
assets—including sensitive assets, sensitive ( | Analysis (MIA), Functional Dependency Network Analysis 
resources, and sensitive functions—or the (FDNA), and Mission Threat Analysis. 


vendor's software. 


e The processresultsin an inventory of critical 
assets used by the vendor's software. 
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D.2.1.2 Threats to the software and 
weaknesses within its design are 
continuousiy identified and assessed. 


Test Reguiremenis 


D.2.1.2.a Examine vendor evidence, including 
process documentation and assessment results 
to confirm the following: 


A mature process exists to identify, assess, 
and monitor software threats and design 
weaknesses (i.e., flaws). 


The assessment accounis for all software 
inputs/outputs, process/data flows, trust 
boundaries and decision points, and how they 
may be exploited by an attacker. 


The assessment accounis for the entire code 
base, including how the use of third-party, 
open-source, or shared componenis or 
libraries, APls, services, and applications 
used for the delivery and operation of the 
software may be leveraged in an attack. 


The assessmeni results in a recorded 
inventory of threats and design flaws. 


Assessmenis are routinely performed to 
account for changes to existing or the 
emergence of new threats or design flaws. 


D.2.1.2.b When open-source software 
componenis are utilized as part of the software, 
examine vendor evidence, including process 
documentation and assessment results to confirm 
ihese componenis are managed as follows: 


An inventory of open-source componenis 
used in the vendor's software is maintained. 


A mature process exists to analyze and 
mitigate the use of open-source componenis 
with known vulnerabilities. 


The vendor monitors vulnerabilities in open- 
source componenis throughout their use or 
inclusion in the vendor's software. 


An appropriate patching strategy for open- 
source componenis is defined. 


Guidance 


Determining how to effectively secure and defend 
software against attacks reguires a thorough 
understanding of the specific threats and vulnerabilities 
applicable to the vendor's software. This typically involves 
understanding: 


» Themotivations an attacker may have for attacking 
software. 


» oWeaknessesin the software design that an attacker 
might attempi to exploit. 


» The exploitability of identified weaknesses. 
» Theimpactof a successful attack. 


This information helps the vendor to identify the threats 
and design flaws that present the most significant and 
immediate risk, and to prioritize remediation activities 
necessary to address them. 


Information regarding software threats can be obtained 
from a variety of sources, both external and internal. 
Examples of external sources include publications from 
organizations such as SANS, MITRE, and CERT that 
specialize in tracking common system vulnerabilities and 
attack technigues, or industry-specific sources that 
provide threat intelligence for specific sectors, such as 
FS-ISAC for the financial services industry and R-CISC 
for the retail industry. Other external sources of threat 
information and design weaknesses could include 
technology vendors, open-source user communities, 
industry publications, and academic papers. Internal 
sources could include reports from internal research and 
design teams, formal threat models, or actual activity data 
from internal security or operations teams. 


(continued on next page) 
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Security Reguiremenits Test Reguiremenis 


D.2.1.2.c Examine assessment results for the 
selected software to confirm the following: 


» All software inputs/outputs, process/data 
flows, trust boundaries, and decision points 
were considered during the assessment. 


» The entire code base, including how the use 
of third-party, open-source or shared 
componenis or libraries, APls, services, and 
applications used for the delivery and 
operation of the software were considered 
during the assessmenit. 


Guidance 


When open-source software componenis are used, the 
vendor should consider any risks associated with the use 
of the open-source componenis and the extent to which 
the open-source software provider manages the security 
of those components. Additionally, the vendor will need to 
confirm that support—including up-to-date security 
patches—is available (whether provided by an internal or 
external entity) for the open-source component. The use 
of open-source componenis should be supported by a 
clear policy about how those componenis are evaluated 
and implemented. A reliable support system should be in 
place to identify errors or problems and evaluate and 
address them in a timely manner. 


When vulnerabilities are identified in open-source 
componenis that are applicable to their software, vendors 
should have processes in place to analyze those 
vulnerabilities and update the componenis to appropriate, 
non-vulnerable versions in a timely manner. When 
patches for open-source componenis are no longer 
available, those components should be replaced by 
actively supported ones. Vendors should identify and 
establish sources and processes for managing 
vulnerabilities in open-source components that are 
appropriate for their software design and release 
freguency. 
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Security Reguiremenits Test Reguiremenis Guidance 
D.2.1.3 Software security controls are D.2.1.3.a Examine vendor evidence, including To ensure that its software is resistant to attacks, vendors 
implemented in the software to mitigate process documentation and software-specific must implemeni software-specific controls or Ni 
threats and design weaknesses. threat and design information, to confirm the countermeasures in their software to mitigate the specific 
following: threats and design weaknesses. Examples of such 


i e controls include the use of multi-factor authentication 
* o A mature process exisis for defining software- | mechanisms to preveni unauthorized individuals gaining 


specific security reguiremenis and access to critical assets, and logging mechanisms to 
implementing software security controls detect if and when authentication mechanisms might have 
within the software to mitigate software been circumvented. Other examples include the use of 
threats and design flaws. input validation routines or parameterized gueries to 

» o Decisions on whether and how to mitigate a protect software from SOL-injection attacks. Except 
specific threat or design flaw are recorded, where specific software security controls and 
justified, and approved by appropriate countermeasures are defined within this standard, it is up 
personnel. to the vendor to determine the most appropriate software 


security conirols to implemenit. The specific controls used 
will be dependent on the software threats identified, as 
well as the software's architecture, the software's 


» (o Anyremaining residual risk is recorded, 
justified, and approved by appropriate 


ersonnel. i k il 
p intended function, the data it handles, and the external 
D.2.1.3.b Examine evidence and interview resources İt utilizes. 
personnel to confirm the following: Evidence to support this security objective may include 


software-specific reguiremenis documentation, feature 
lists, security control inventories, change-managemenit 
documentation, risk assessmenit reports, test results, or 


» (o Decisions on whether and how to mitigate a 
specific threat or design flaw are reasonabiy 


al e , e any other evidence or information that clearly and 
»  Anyremaining residual risk is reasonabiy consistentiy shows that the vendor implements and 
justified. maintains security controls in software to address the 


: , ğ risks to that software. 
D.2.1.3.c Examine vendor evidence to confirm 


that security controls have been implemented to 
mitigate all identified threats and design flaws. 
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D.2.1.4 Failures or weaknesses in software 
security conitrols are detected. Weak or 
ineffective security controls are updated, 
augmented, or replaced. 


Test Reguiremenis 


D.2.1.4.a Examine vendor evidence and interview 
personnel to confirm the following: 


A mature process exists to identify weak or 
ineffective software security controls and to 
update, augmeni, or replace them. 


The criteria for determining a weak or 
ineffective security control are defined and 
justified. 

The process involves monitoring security 
control effectiveness throughout the software 
lifecycle. 


Weak or ineffective security controls are 
updated, augmented, or replaced in a timely 
manner upon detection. 


D.2.1.4.b Examine vendor evidence, including 
software-specific data or test results, and details 
of software-specific updates to confirm the 
following: 


Security controls that have been deemed 
“weak” or “ineffective” have been updated, 
augmented, or replaced. 


Decisions on whether and how to replace and 
augment weak or ineffective security controls 
are made in accordance with defined criteria 
and with D.2.1.3. 


Guidance 


Vendors should monitor and/or routinely test their 
software to confirm that implemented software security 
conitrols remain appropriate (i.e., fit for purpose) and 
effective for sufficiently mitigating evolving risks or design 
flaws. For example, a software-specific security 
reguirement may call for cryptography to be used to 
protect software communications. While the use of SSL 
may have been sufficient upon the initial design and 
release of the software, SSL is no longer sufficient to 
adeguately protect communications as new threats and 
attack methods have significantly reduced its 
effectiveness as a security control. Therefore, it İs 
imperative that vendors have processes in place to 
continuously monitor implemented security controls to 
make sure that they remain appropriate and sufficient to 
mitigate evolving threats and design flaws throughout the 
entire lifetime of the software. 


Evidence to support this reguirement might include 
software-specific documentation, features lists, software- 
specific security control inventories, change-managemenit 
documentation, risk-assessment reports, penetration test 
results, output from active s, bug bouniy program data, or 
any other evidence or information that clearly and 
consistently shows that the effectiveness of software 
security controls is monitored and that software-specific 
software security controls are updated, augmented, or 
replaced when no longer effective at satisfying their 
intended purpose of resisting attacks. 
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D.2.2 Vulnerability Detection and Mitigation 


Test Reguiremenis 


Guidance 


Detect and mitigate vulnerabilities in software to ensure that its software remains resistant to attacks throughout its entire lifecycle. 


D.2.2.1 Existing and emerging software 
vulnerabilities are detected in a timely 
manner. 


D.2.2.1.a Examine vendor evidence and interview 
personnel to confirm the following: 


A mature process exists for testing software 
for the existence and emergence of 
vulnerabilities (i.e., security testing). 


Tools or methods used for security testing are 
appropriate for detecting applicable 
vulnerabilities in the vendor's software, and 
are suitable for the software architectures, 
and the software development languages and 
frameworks employed. 


Security testing is performed throughout the 
entire software lifecycle, including after 
release. 


Security testing accounis for the entire code 
base, including detecting vulnerabilities in any 
third-party, open-source, and shared 
componenis and libraries. 


Security testing is performed by authorized 
and objective vendor personnel or third 
parties. 

Security testing results in an inventory of 
identified vulnerabilities. 

Security-testing details including the tools 
used, their configurations, and the specific 
tesis performed are recorded and retained. 


Software should be monitored or routinely tested to 
confirm that vulnerabilities are identified and mitigated 
before software or code updates are released into 
production, and to address any vulnerabilities that may 
have been discovered since release. 


Routine security testing should be performed prior to or 
as part of the code-commit process to detect coding 
errors or the use of insecure functions. It could also be 
performed during unit, integration, regression, or 
interoperability testing, or during separate security testing. 
Security testing should be performed consistentiy and 
throughout all stages of the software lifecycle, including 
during various pre-release phases of the software- 
development process and after code release, to ensure 
ihe software is free from vulnerabilities upon launch and 
any subseguent updates, and remains free from 
vulnerabilities throughout its lifetime. 


Security testing should be performed by appropriately 
skilled vendor personnel or third parties. In addition, 
security testing personnel should be able to conduci tests 
in an objective way and be authorized to escalate any 
identified vulnerabilities to appropriate management or 
development personnel so they can be properly 
addressed. 


Evidence to support this security objective could include 
software-specific reguiremenis documentation, security 
test results, feature lists, change-managemenit 
documentation, entries in the vendor's workflow (bug 
tracking) database, or any other evidence or information 
that clearly and consistently shows that security testing İs 
performed routinely to detect vulnerabilities in code prior 
to release as well as vulnerabilities discovered since code 
launch. 
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Security Reguiremenits 


Test Reguiremenis 


D.2.2.1.b Examine evidence, including software- 
specific security testing configurations and test 
results to confirm the following: 


»e (o Security-testing tools are configured in a way 
that is appropriate for the intended tests 
performed. 


» (o Security testing accounis for the entire code 
base, including detecting vulnerabilities in any 
third-party, open-source, and shared 
componenis and libraries. 


» (o Security testing was performed by authorized 
and objective vendor personnel or third 
parties. 


D.2.2.1.c Examine vendor evidence and interview 
personnel to confirm that personnel responsible 
for testing are knowledgeable and skilled in the 
following areas in accordance with D1.1.3: 


» o Software security testing technigues 


» (o Security testing tools settings, configuration, 
and recommended usage 


D.2.2.1.d Examine software-specific testing 
results to confirm that security testing İs 
performed throughout the software lifecycle. 


Guidance 
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Security Reguiremenits 


D.2.2.2 Newly discovered vulnerabilities are 
fixed in a tmely manner. The reintroduction 
of similar or previously resolved 
vulnerabilities is prevented. 


Test Reguiremenis 


D.2.2.2.a Examine vendor evidence and interview 
personnel to confirm the following: 


» Amatureprocessexistsfor distributing and 
deploying fixes for newly discovered 
vulnerabilities and preventing the 
reintroduction of previously resolved 
vulnerabilities. 


»* (The process includes methodsto prevent 
previously resolved vulnerabilities or other 
similar vulnerabilities from being reintroduced 
into the software. 


» o The criteria for determining the “criticality” or 
“severity” of vulnerabilities and how to 
address vulnerabilities are defined and 
justified. 

»e oFixesto address vulnerabilities in production 
code are made available and deployed in 
accordance with defined criteria. 


» Decisionsnotto provide fixes in accordance 
with defined criteria are approved and 
justified by appropriate personnel on a case- 
by-case basis. 


D.2.2.2.b For a sample of vendor software, 
examine software-specific security-testing results 
and the details of software updates to confirm that 
security fixes are made available and deployed 
(where applicable) in accordance with defined 
criteria. 


D.2.2.2.c For the sample of vendor software, 
interview personnel to confirm that decisions not 
to provide security fixes in accordance with 
defined criteria are justified by appropriate 
personnel. 


Guidance 


Vulnerabilities should be addressed in a way 
commensurate with the risk they pose to the software or 
its stakeholders. The most critical or severe vulnerabilities 
(i.e., those with the highest exploitability and/or the 
greatest impact to stakeholders) should be patched 
immediately, followed by those with moderate-to-low 
exploitability and/or impact. Additionally, the discovery of 
new classes of vulnerabilities should be used as a source 
of input for process improvemeni. Software should be 
reviewed for instances of similar vulnerabilities, and the 
vendor's development processes updated to enable 
detection and mitigation of such vulnerabilities in the 
future. 


In some cases, it may be impractical for a vendor to fix all 
identified vulnerabilities prior to the release of production 
code or updates. In such circumstances, the vendor 
should have a methodology with clear criteria defined for 
prioritizing vulnerability fixes. The default outcome should 
always be that vulnerabilities are fixed before the software 
is released. In cases where it is not possible to fix a 
vulnerability prior to release, an exception process 
involving management at a level commensurate with the 
severity of the vulnerability should be invoked. The 
process should include documented justification for why a 
fix for was not provided to address the vulnerability. 


If it is not possible to mitigate a certain vulnerability prior 
to release, the vendor should provide stakeholders with 
additional guidance to mitigate the risk of exploitation until 
a security update to fix the vulnerability can be made 
available. 
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Under no circumstances should a previously resolved 
vulnerability be reintroduced into production code, nor 
should similar vulnerabilities within the same class of 
vulnerabilities be reintroduced. Additional assurance 
processes and safeguards should be implemented to 
ensure that such incidents are avoided. The specific 
processes to prevent such occurrences will largely 
depend about how the vendor's software is structured and 
how the vendor manages software updates. It is up to the 
vendor to determine the most appropriate methods to 
prevent the reintroduction of vulnerabilities into production 
code. 
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D.3 Secure Software and Data Management 


The confidentiality and integrity of software and its oritical assets are maintained throughout the software lifecycle. 


Security Reguiremenis | 


D.3.1 Change Management 


Test Reguiremenis 


Identify and manage all software changes throughout the software lifecycle. 


Guidance 


D.3.1.1 All changes to software are 
identified, assessed, and approved. 


D.3.1.1.a Examine vendor evidence and interview 
personnel to confirm: 


A mature process exists to identify, assess, and 
approve all changes to software. 


The process includes an analysis of the security 
impact of all changes. 


The process results in an inventory of all 
changes made to software, including a record of 
ihe determined security impact. 


All change-managemenit decisions are 
recorded. 


All implemented changes are authorized by 
responsible personnel. 


The inventory of changes identifies the 
individual creator of the code and individual 
authorizing the change, for each code change. 


All decisions to implement changes are justified. 


D.3.1.1.b For a sample of changes, examine 
software-specific and change-specific 
documentation or evidence to confirm the following: 


All changes are authorized by responsible 
personnel. 


All decisions to implement the changes are 
recorded and include justification for the 
change. 


The inventory of changes clearly identifies the 
individual creator of the code and the individual 
authorizing the change, for each code change. 


All changes to software should be defined, documented, 
approved, and tracked so that any vulnerabilities 
attributed to such changes may be identified and resolved 
as guickiy as possible. The harder it is to trace 
vulnerabilities back to the changes that introduced them, 
the longer it takes to resolve those vulnerabilities, which 
places the software at greater risk of attack or 
compromise. 


It is imperative to understand the security risk of a change 
to the software to ensure that it is addressed accordingly. 
It often involves understanding the types of software 
functionality the change impacis (e.g., functionality that 
deals with encryption or authentication processes), the 
iype of information assets that the functionality can 
access or manipulate, the likelihood of successful 
vulnerability exploitation, and the impact a successtful 
attack may have on stakeholders. 
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Security Reguiremenis 


D.3.1.2 All software versions are uniguely 
identified and tracked throughout the 
software lifecycle. 


Test Reguiremenis 


D.3.1.2.a Examine vendor evidence and interview 
personnel to confirm the following: 


A formal system or methodology for uniguely 
identifying each version of software is defined. 


The system or methodology includes arranging 
unigue identifiers or version elements in a 
seguential and logical way. 


All changes to software functionality are clearly 
associated with a unigue software version. 


D.3.1.2.b For a sample of software updates, 
examine vendor evidence, including change-specific 
documentation, to confirm the following: 


Software versions are updated in accordance 
with the defined versioning system or 
methodology. 


All changes to software functionality are clearly 
associated with a unigue software version. 


Guidance 


Without a thoroughly defined versioning methodology, 
changes to software may not be properly identified, and 
customers and integrators/resellers may not understand 
the impact of such changes. 


The system or methodology adopted by the vendor 
should allow different release versions of a software 
product to be easily distinguishable. To ensure a software 
version accurately represenis the release version, the 
versioning system or methodology should be integrated 
with applicable lifecycle functions, such as code control 
and change management. 


The versioning system or methodology should 
encompass all changes to all relevant software 
componenis. As several iterations of a software 
component may be produced for a single software 
release, the versioning system or methodology should 
easily identify the version of each component associated 
with a specific software release version. 


The method used for identifying the software release 
versions—e.g., a version numbering seheme—should be 
documented and reflect the type of change and its impact 
on the software. 
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Security Reguiremenis 


D.3.2 Software integrity Protection 


Test Reguiremenis 


The integrity of software is protected throughout the software lifecycle. 


Guidance 


D.3.2.1 The integrity of all software code, 
including third-party componenis, is 
maintained throughout the entire software 
lifecycle. 


D.3.2.2 Software releases and updates 
are delivered in a secure way that 
ensures the integrity of the update code. 


D.3.2.1.a Examine evidence, interview personnel, 
and observe tools and processes to confirm: 


» A mature process, mechanism, and/or tool(s) 
exist to protect the integrity of the software 
code, including third-party componenis. 


» (The processes, mechanisms, and/or tools are 
reasonable and appropriate for protecting the 
integrity of software code. 


» o Processes, mechanisms, or the use of tools 
results in the timely detection of any 
unauthorized attempis to tamper with or access 
software code. 


» (o Unauthorized attempis to tamper with or access 
software code are investigated in a timely 
manner. 


D.3.2.2.a Examine vendor evidence, interview 
personnel, and observe tools and processes to 
confirm the following: 


» A mature process, mechanism, and/or tool(s) 
exist to ensure the integrity of software updates 
during delivery. 


» The processes, mechanisms, andor tools are 
reasonable and appropriate for protecting the 
update code. 


» o Processes, mechanisms, and/or the use of tools 
results in the secure delivery of update code. 


Effective software-code control practices help ensure that 
all changes to code are authorized and performed only by 
those with a legitimate reason to change the code. 
Examples of these practices include code check-in and 
check-out procedures with strict access controls, anda 
comparison—e.g., using a checksum—immediately 
before updating code to confirm that the last approved 
version has not been changed. It is important that controls 
cover all software code, third-party componenis and 
libraries, configuration files, etc. that are controlled by the 
vendor. 


The integrity and confidentiality of these assets must be 
maintained, as they often contain sensitive assets such 
as intellectual property (e.g., business logic), logic of 
security functions, configuration of cryptographic functions 
(e.g., software-protected cryptography), etc. 


Effective software-code control practices help ensure that 
all changes to code are authorized and performed only by 
those with a legitimate reason to change the code. 
Examples of these practices include code check-in and 
check-out procedures with strict access controls, anda 
comparison—e.g., using a checksum—immediately 
before updating code to confirm that the last approved 
version has not been changed. It is important that controls 
cover all software code, third-party components and 
libraries, configuration files, etc. that are controlled by the 
vendor. 


The integrity and confidentiality of these assets must be 
maintained, as they often contain sensitive assets such 
as intellectual property (e.g., business logic), logic of 
security functions, configuration of cryptographic functions 
(e.g., software-protected cryptography), etc. 


Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0— Appendix D 
© 2022 PCI Security Standards Council, LLC. All rights reserved. 


November 2022 
Page 240 


» Security Li 
Standards Council 


Security Reguiremenis 


D.3.3 Sensitive Data Protection 


Test Reguiremenis 


The confidentiality of sensitive production data is maintained on vendor systems. 


Guidance 


D.3.3.1 Sensitive production data is only 
collected and retained on vendor systems 
where there is a legitimate business or 
technical need. 


D.3.3.1.a Examine vendor evidence and interview 
personnel to confirm the following: 


A mature process exists to record and authorize 
the collection and retention of any sensitive 
production data. 

An inventory of sensitive production data 


captured or stored by the vendor's products and 
services is maintained. 


Decisions to use sensitive production data are 
approved by appropriate vendor personnel. 


Decisions to use sensitive production data are 
recorded and reasonabily justified. 


To protect the confidentiality of any sensitive production 
data—ihat is, sensitive assets that is owned by and entity 
other than the vendor— and stored on vendor systems, 
such data should never be used for purposes other than 
those for which the data was originally collected. If the 
vendor provides services to its customers that could result 
in the collection of sensitive production data (e.g., for 
troubleshooting or debugging purposes), the vendor 
should record those specific data elements it collects and 
retains, and clearly communicate what data elemenis are 
collected and why they are collected to its customers and 
other relevant stakeholders. 


The inventory of sensitive production data retained by the 
vendor should include identification of the specific data 
elemenis captured, whether storage of each elementi is 
permitted, and the security conitrols reguireJd—e.g., to 
protect confidentiality and/or integrity—for each data 
element during storage and transmission. 


D.3.3.2 Sensitive production data is 
protected when retained on vendor 
systems and securely deleted when no 
longer needed. 


D.3.3.2.a Examine vendor evidence and interview 
personnel to confirm that a mature process exists tO 
ensure sensitive production data is protected when 
retained on vendor systems and is securely deleted 
when no longer needed. 


D.3.3.2.b Examine vendor evidence and observe a 
sample of vendor systems to confirm the following: 


Sensitive production data is not resident on 
vendor systems unless appropriate evidence of 
approval and justification exists. 


Sensitive production data is appropriately 
protected where it is retained. 


Secure deletion processes or mechanisms are 
sufficient to render sensitive production data 
irretrievable. 


When vendors collect sensitive production data from their 
customers—e.g., for debugging or other customer support 
purposes—ihe vendor should coordinate with its 
stakeholders to identify which data elemenis reguire 
protection. Vendor stakeholders may have their own 
definition and associated security reguiremenis for 
sensitive assets, and appropriate protection efforts should 
be agreed upon by both parties. 


When the vendor collects or retains sensitive production 
data, the vendor should ensure it is secureJ—e.g., by 
using robust access control measures and/or strong 
cryptography with industry-accepted key-management 
processes. As soon asit is no longer needed for its 
collected purpose, sensitive production data should be 
securely deleted such that it is not possible to reconstruct 
or recover the data from any vendor system. 
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D.4 Security Communications 


The vendor provides timely information to its stakeholders (e.g., customers, installers, integrators, etc.) regarding security issues affecting its 
software, and thorough guidance on secure software implementation, configuration, operation, and updates. 


Security Reguiremenis 


D.4.1 Vendor Implementation Guidance 


Test Reguiremenis 


Guidance 


Stakeholders are provided with clear and thorough guidance on the secure implementation, configuration, and operation of its software. 


D.4.1.1 The vendor provides stakeholders 
with clear and thorough guidance on the 
secure implementation, configuration, and 
operation of its software. 


D.4.1.1.a Examine vendor evidence and interview 
personnel to confirm the following: 


A mature process exists to produce, maintain, 
and make available to stakeholders' guidance 
on the secure implementation, configuration, 
and operation of its software. 


The implementation guidance includes 
documentation of all configurable security- 
related options and parameters for the 
vendor's software, and instructions for 
properly configuring and securing each of 
those options and parameters. 


D.4.1.1.b For a sample of vendor software, 
examine software-specific documentation and 
materials to confirm that the vendor provides and 
maintains guidance on the secure configuration of 
each security-related option or parameter 
available in the vendor's software. 


When followed, the vendor's implementation guidance 
provides assurance that the software and patches are 
securely installed, configured, and maintained in the 
customer environment, and that all desired security 
functionality is active and working as intended. The 
guidance should cover all options and functionality 
available to software users that could affect the security of 
ihe software or the data it interacts with. The guidance 
should also include secure configuration options for any 
componenis provided with or supported by the software, 
such as external software and underlying platforms. 


Examples of configurable options include: 
» o Changing default credentials and passwords. 


» (o Enabling and disabling application accounis, 
services, and features. 


» oChangesin resource access permissions. 


» o İntegration with third-pariy cryptographic libraries, 
RNGş, etc. 

Following the secure implementation guidance should 

result in a secure configuration across all configurable 

options. 
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Security Reguiremenis Test Reguiremenis Guidance 
D.4.1.2 Secure implementation guidance D.4.1.2.a Examine vendor evidence to confirm the | As the vendor is expected to continuously identify, 
includes detailed instructions about how to following: assess, and manage risks to its software, the vendor's 
securely install, configure, and maintain all * © The secure implementation guidance software-change processes should include determining 
software components and supported includes instructions about how to securely the impact of the change to vendor guidance. Software 
platforms. install or initialize, configure, and maintain the o a el ml ie ELM 
ötme. should result in an update to the secure implementation 
guidance. 
» (The secure implementation guidance is 
sufficientiy detailed. 
» (Evidence exists or is obtainedto show that 
following the secure implementation guidance 
results in a secure software configuration. 
D.4.1.3 Secure implementation guidance is D.4.1.3.a Examine vendor evidence and interview 
aligned with software updates. personnel to confirm the following: 
» The processto produce and maintain secure 
implementation guidance includes generation 
of updated guidance when new software 
updates are released, or security-related 
options or parameters are introduced or 
modified. 
» (o Secure implementation guidance is reviewed 
at least annually for accuracy even if updates 
to security-related options and parameters 
are not İSsued. 
D.4.1.3.b For a sample of software updates, 
examine secure implementation guidance as well 
as details of the software updates to confirm that 
as security-related options and parameters are 
updated or added, the secure implementation 
guidance is updated. 
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Security Reguiremenits | Test Reguiremenis | Guidance 


D.4.2 Stakeholder Communications 
Communication channels are maintained with stakeholders regarding potential security issues and mitigation options. 


D.4.2.1 Communication channels are D.4.2.1.a Examine evidence and interview Vendors should monitor the threat landscape to identify 
defined and made available for customers, personnel to confirm the following: new vulnerabilities and security issues that impact their 
installers, integrators, and other relevant * © A mature process exists to support open, bi- software on the market. Vendors should also provide 
parties to report and receive information on directional communications with stakeholders | 9PSN nes oi communication to enable researchers or 
security issues and mitigation options. for reporting and receiving security other stakeholders to report newly discovered 


vulnerabilities in the vendor's products and services. 
Communication channels could include a publicly 
disclosed e-mail address, website page. or other method 


information regarding the vendor's products 
and services. 


» — Communication channels provide to facilitate interactions with external researchers—e.g., 
stakeholders the ability to report security- through a formal bug bouniy program. The vendor should 
related issues and to receive timely status also maintain teams to respond to such reports and drive 
updates on their gueries. processes to fix vulnerabilities in the vendor's software. 

» (The vendor maintains resources to respond In addition to supporting the receipt of information about 
to reporis or inguiries regarding the security vulnerabilities within its software products, the vendor 
of the vendor's products and services. should also issue communications to customers, 

ı installers, and integrators to provide information about 
D.4.2.2 Stakeholders are notified about D.4.2.2.a Examine evidence and interview known vulnerabilities and when fixes will be available. 
security updates in a timely manner. personnel to confirm a mature process &xİsts to Fixes/patches should be developed and released in a 

notify stakeholders about security updates in a timely manner, based on criticality and in accordance with 

timely manner. D.2.2.2. 

: i i Ni Ni Vendor security notifications should include the criticality 
D.4.2.3 When security updates are not D.4.2.3.a Examine evidence and interview and potential impact of the vulnerability, as well as clear 
readily available to address known personnel to contfirm that processes include guidance for addressing the vulnerability (€.g., how to 
vulnerabilities or exploits, security providing stakeholders with instructions for install a patch or software update). When a fix is not 
notifications are İssued to all relevant mitigating the threat or reducing the likelihood readily available, the vendor should communicate the risk 
stakeholders to provide instructions for and/or impact of exploitation of known security and provide guidance on mitigation options. 
mitigating the risks associated with the issues for which a timely patch is not provided. (continued on next page) 


known vulnerabilities and exploits. 
D.4.2.3.b For a sample of software security 


updates, examine stakeholder communications, 
product-specific documentation, security-testing 
results, and other materials to confirm that where 
known vulnerabilities are not addressed in the 
security updates, risk mitigation instructions are 
provided to stakeholders. 
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Security Reguiremenits Test Reguiremenis Guidance 


Vendor-initiated communications could include e-mail 
notifications, website alerts, written notices, social media 
posts, and any other channels the vendor maintains for 
stakeholder engagement. Communication channels 
should be publicized so that stakeholders know how to 
access them (e.g., by signing up for e-mail notifications). 
Vendor contact information should also be provided for 
stakeholders to submit further guestions regarding 
security notifications. 


D.4.3 Software Update Information 
Stakeholders are provided with detailed explanations of all software changes. 


D.4.3.1 Upon release of any software D.4.3.1.a Examine evidence and interview Release notes should be provided for all software 
updates, a summary of the specific changes | personnel to confirm the following: updates, including details of any impact on software 
made to the software is provided to * © A mature process exists to communicate all functionality and security controls. Informing stakeholders 


of the impact of a software update enables them to make 


stakeholders. 
e elele Lp informed decisions on whether and when to implement it. 


software updates. 


»* The processresultsin a clear and detailed 
summary of all software changes. 


»e (The change summary information clearly 
outlines the specific software functionality 
impacted by the changes. 


»e (o Change details are easily accessible to 
stakeholders. 


D.4.3.1.b For a sample of software updates, 
examine publicly available information or 
notifications regarding the software updates to 
confirm the following: 


»e (o Change summary information is made 
available to stakeholders. 


» (Change summa!y information accurately 
reflects the changes made to the software. 
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Appendix E MSR Security Reguiremenits 


This appendix provides the security reguiremenis for any non-PTS approved MSR devices used with an MPoC Solution. The security and 
testing reguirements described in this appendix provide a framework for protecting the confidentiality and integrity of account data captured 
using a non-PTS approved MSR, used in combination with the existing elements of an overall MPoC Solution. Adding optional support to 
process magnetic sitripe transactions with a magnetic stripe only reader allows merchants to use a single solution to accept paymenis, where 
magnetic stripe acceptance is desired but the PCI PTS SCRP device used with the MPoC Solution does not support MSR functionality. 


Only reguirements for the non-PTS approved MSR device itself are covered in this Appendix. Reguiremenis for the integration and use ofa 
non-PTS approved MSR device within an overall MPoC Solution are covered within the MPoC reguiremenis listed in the body of this 
document. 


MSR Validation and Testing Reguirements 


Magnetic stripe data input to an MPoC Solution must be read by an approved device. This device may be a PCI PTS SCRP, tested and 
approved through the PCI PTS POÖJ program, or a non-PTS approved MSR tested according to the reguiremenis in this appendix. Regardless 
of validation, magnetic stripe-based transactions may not be used by an MPo€C Solution with PIN acceptance. 


Many of the testing reguirements in this appendix are based on, and reference, the PCI PTS POJ v6.x Derived Test Reguirements document. 
However, this appendix references only a subset of the reguiremenis that would be tested against a PCI PTS SCRP device and exclude all 
physical security testing reguirements. When the PCI PTS POJ testing reguiremenis reguire testing for data or implementations that are not 
provided by the MSR device — such as PIN acceptance and processing, or physical security — these reguirements are not to be assessed. 


E.1 Account Data Input 


Security Reguiremenits Test Reguiremenis Guidance 
E.1.1 A non-PTS approved MSR device E.1.1.a The tester must confirm through Support for non-PTS approved MSR devices is provided 
must only provide for the acceptance of examination and observation that the non-PTS to accommodate magnetic stripe cards. Acceptance of 
account data through a magnetic readhead approved MSR does not provide any other any other account data presenimenit method, such as 
interface. methods for account data acceptance other than (| Manual entry, contact or contactless chip, may not be 
through a magnetic readhead interface. implemented in a non-PTS approved MSR device. 
Mobile Payments on COTS Security and Test Reguiremenis, Version 1.0 — Appendix E November 2022 


© 2022 PCI Security Standards Council, LLC. All rights reserved. Page 246 


» Security . 
Standards Council 


E.2 No Account Data Storage 


Security Reguirements 


E.2.1 A non-PTS approved MSR device 
must not store account data. 


Test Reguiremenis 


E.2.1.a The tester must confirm through 
examination and observation that the non-PTS 
approved MSR does not store account data. It 
must not be possible for more than one set of 
magnetic stripe data to be present within the 
memory of the non-PTS approved MSR device at 
any one time. 


Guidance 


Account data should be transferred from the non-PTS 
approved MSR device to the MPoC Software as soon as 
practicable. Although there may be some delay between 
the read of the data and the transfer of the data to the 
MPoC Software, there can be only one set of data within 
the non-PTS approved MSR device at any one time. 


E.3 Account Data Processing 


Security Reguiremenits 


E.3.1 All account data is either encrypted 
immediately upon entry or entered in 
cleartext into a secure device and 
processed within the secure controller of the 
device. 


Test Reguiremenis 


E.3.1.a The tester must evaluate the non-PTS 
approved MSR to PCI PTS POJ v6.x DTR A11 
and confirm compliance to all applicable 
reguiremenis. 


Guidance 


Account data should be transferred from the non-PTS 
approved MSR device to the MPoC Software as soon as 
practicable. Although there may be some delay between 
the read of the data and the transfer of the data to the 
MPoC Software, there can be only one set of data within 
the non-PTS approved MSR device at any one time. 


E.4 Firmware Updates 


Security Reguiremenits 


E.4.1 Where the device implemenis 
firmware, the device must support firmware 
updates. The device must cryptographicaliy 
authenticate the firmware and if the 
authenticity is not confirmed, the firmware 
update is rejected and deleted. 

The update mechanism ensures security 
(i.e., integrity, mutual authentication, and 
protection against replay) by using an 
appropriate and declared security protocol 
when using network connections. 


Test Reguiremenis 


E.4.1.a The tester must evaluate the non-PTS 
approved MSR to PCI PTS POJ v6.x DTR B2 and 
confirm compliance to all applicable reguiremenis. 


Guidance 


Support for network connections, or network-based 
updates, is not reguired. However, where such updates 
are supported, then a declared security protocol is 
reguired. This security protocol is tested under the 
reguiremenis of the “Communication and Interfaces” 
section (PCI PTS POJ v6.x Module 3). 
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E.5 Protection of Sensitive Services 


Security Reguirements 


E.5.1 Access to sensitive services reguires 
authentication. Sensitive services provide 
access to the underlying sensitive functions. 
Sensitive functions are those functions that 
process sensitive assets such as 
cryptographic keys, account data, and 
passwords/authentication codes. Entering or 
exiting sensitive service shall not reveal or 
otherwise affect sensitive assets. 


Test Reguiremenis 


E.5.1.a The tester must evaluate the non-PTS 
approved MSR to PCI PTS POL v6.x DTR B5 and 
confirm compliance to all applicable reguiremenis. 


Guidance 


Although PCI PTS POJ v6.x B5 includes testing 
reguiremenis that cover aspecis of PIN security, a non- 
PTS approved MSR device must not allow for the entry or 
processing of cardholder PINS. 


E.6 Sensitive Service Limits 


Security Reguiremenis Test Reguiremenis Guidance 
E.6.1 To minimize the risks from E.6.1.a The tester must evaluate the non-PTS 
unauthorized use of sensitive services, approved MSR to PCI PTS POJ v6.x DTR B6 and 
limits on the number of actions that can be confirm compliance to all applicable reguiremenis. 
performed and a time limit shall be imposed, 
after which the device is forced to return to 
its normal mode. 
E./7 Key Management 
Security Reguiremenits Test Reguiremenis Guidance 


E.7.1 The key management technigues 
implemented in the device conform to 
ISO11568 and/or ANSI X9.24. When 
multiple cryptographic keys are supported, 
key-managemeni technigues must support 
key blocks as defined in DTR B9. 


E.7.1.a The tester must evaluate the non-PTS 
approved MSR to PCI PTS POJ v6.x DTR B9 and 
confirm compliance to all applicable reguiremenis. 


Implementation of key blocks is not reguired for devices 
that support only a single encryption key (i.e., for the 
encryption of account data from the magnetic stripe). 
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E.8 Encryption Mechanism 


Security Reguirements 


E.8.1 All account data shall be encrypted 
using only ANSI X9 or ISO-approved 
encryption algorithms (e.g., AES) and 
should use ANSI X9 or ISO-approved 
modes of operation. 


Test Reguiremenis 


E.8.1.a The tester must evaluate the non-PTS 
approved MSR to PCI PTS PO v6.x DTR B10 
and confirm compliance to all applicable 
reguiremenis. 


E.8.1.b The tester must confirm through 
examination and observation that the non-PTS 
approved MSR uses only algorithms and key 


lengths that provide an effective key strength of at 


least 128 bits. 


Guidance 


Encryption algorithms used to protect account data are 
reguired to provide at least 128 bits of effective strength. 
TDEA encryption is not permitted to be used by a non- 
PTS approved MSR device for any security services. 


Use of AES encryption for non-PTS approved MSR 
devices is recommended. 


E.9 Remote Access 


Security Reguirements 


E.9.1 If the device can be accessed 
remotely for the purposes of administration, 
all access attempts must be 
cryptographically authenticated. If the 
authenticity of the access reguest cannot be 
confirmed, the access reguesi is denied. 


Test Reguiremenits 


E.9.1.a The tester must evaluate the non-PTS 
approved MSR to PCI PTS POJ v6.x DTR B22 
and confirm compliance to all applicable 
reguiremenis. 


Guidance 


If the device supports remote access, cryptographic keys 
Used to secure this access are reguired to be different 
from the keys used for account data encryption. This is 
tested under the key management reguiremenis. 


E.10 Output of Cleartext Account Data 


Test Reguiremenis 


Guidance 


Security Reguirements 


E.10.1 There is no mechanism in the device 
that allows the outputting of cleartext 
account data. 


E.10.1.a The tester must evaluate the non-PTS 
approved MSR to PCI PTS POJ v6.x DTR B23 
and confirm compliance to all applicable 
reguiremenis. 


Although PCI PTS POL v6.x B23 supports the testing of 
devices that provide for a non-encrypting mode, non-PTS 
approved MSR devices are not permitted to implement 
any mode where account data is output in cleartext. 
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E.11 Surrogate PAN Values 


Security Reguirements 


E.11.1 If the device is capable of generating 
surrogate PAN values to be outputted 
outside of the device, it is not possible to 
determine the original PAN knowing only the 
surrogate values. When a hash function is 
used to generate surrogate PAN values: 


»e o İnputtothe hash function mustusea 
salt with minimum length of 64 bits. 

» The saltis kepi secret and appropriately 
protected. 


Test Reguiremenis 


E.11.1.a The tester must evaluate the non-PTS 
approved MSR to PCI PTS POJ v6.x DTR B24 
and confirm compliance to all applicable 
reguiremenis. 


Guidance 


Support for surrogate PAN values is not reguired for non- 
PTS approved MSR devices. 

Non-PTS approved MSRs tested against PCI PTS POJ 
v6.x B24 are not reguired to implement physical tamper 
detection, and the testing reguiremenis that validate 
physical security need not be assessed. 


E.12 Communications and Interfaces 


Security Reguiremenis 


E.12.1 The device must provide for secure 
communications and interfaces, including 
data origin authentication of encrypted 
messages and protections against logical 
anomalies. 


Test Reguiremenis 


E.12.1.a The tester must evaluate the non-PTS 
approved MSR to Module 3 of PCI PTS POJ v6.x 
and confirm compliance to all applicable 
reguiremenis. 


Guidance 


Only applicable sections of the Module 3 reguirements 
must be assessed. For example, reguiremenis covering 
the security of IP protocols need not be assessed against 
devices that do not provide IP connectivity. 

Regardless of interface types supported, testing of 
reguiremenis validating the implementation of data origin 
authentication are always reguired to be assessed. 


E.13 Lifecycle Security Reguirements 


Security Reguirements 


Test Reguiremenis 


Guidance 


E.13.1 The non-PTS approved MSR 
development, manufacturing, and 
distribution processes must be compliant to 
the reguiremenis of PCI PTS POJl v6.x 
Module 4. 


E.13.1.a The tester must evaluate the non-PTS 


approved MSR to Module 4 of PCI PTS POL v6.x 


and confirm compliance to all applicable 
reguiremenis. 


On-site validation of the processes and security controls 
is not reguired. 
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AppendixF Configuration and Use of the STS Tool 


The NIST STS (Statistical Test Suite) is a reference implementation of the statistical tests described in NIST SP 800-22 Revision 1a. 


The tester shall use NIST's STS tool, version 2.1.2 or later, or its mathematical eguivalent. The tester shall verify that the compiled instance of 
ihe STS tool is operating correctiy on the testing device by testing the NIST-provided sample data and comparing the results with those found 
in NIST SP 800-22 Revision 1a (SP800-22r1a), Appendix B. This configuration guidance is for use with STS version 2.1.2, though it will likely 
continue to be applicable to future versions. 


Note: Prior versions of STS include bugs that have been fixed in the current version. Previous versions must not be used unless the critical 
fixes present in the current NIST tool have been backported. At a minimum, prior versions must disable the Lempel-Ziv compression test 
(Hamano 2009) and include fixes to the DFT (Speciral) test (Kim 2004), the Overlapping Template test (Hamano 2007), the Non-Overlapping 
test (NIST 2014), and the “Proportion of Seguences Passing a Test” test interpretation. 


The tester should reguest and obtain a sample of 230 bits from the vendor. The tester should exercise care to verify that the vendor-supplied 
data is interpreted correctly by the STS tool (the STS tool assumes that binary data is in big-endian formatting on all devices). 


The STS testing on the data shall be judged as a "pass" if if passes all of the tests, for both the "Proportion of Seguences Passing a Test" 
interpretation approach and "Uniform Distribution of P-Values" interpretation approach. If the data does not pass all tests, and the failure is 
marginal, the tester should acguire additional data from the vendor and repeat the testing, including both the initial data and the additional 
vendor-supplied data. 


The STS tool should be configured as per guidance provided in SP 800-22 Revision 1a, which is summarized on the next page. 
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The following settings are consistent with the SP 800-22 Revision 1a document: 


Table 11: Configuration Settings 


Configuration Item Setting Reference in Key Below 

Length of bit streams (n) 1,000,000 n must be selected to be consistent with the reguiremenis of all of the tests to be run. The 
Overlapping Templates, Linear Complexity, Random Excursions, and Random Excursions Variant 
tesis all reguire n to be greater than or egual to 106 in order to produce meaningful results. The 
Discrete Fourier Transform (Spectral) test reguires n to egual 106. (See SP 800-22r1a Sections 
2.8.7,2.10.7,2.14.7,2.15.7, and|NIST 2010).) 

Number of bit sireams (sample 1,073 The number of bit seguences (sample size) must be 1,000 or greater in order for the "Proportion of 

size) (M) Seguences Passing a Test" result to be meaningful. (See SP 800-22r1a Section 4.2.1.) This value 
will be 1,073 for the first test, but any additional testing (e.g., further testing to resolve test failures) 
will necessarily include more bit seguences. 

Block Freguency block length 20,000 For the Block Freguency test, if n106, the test block size should be set between 104 and 106. (See 
SP 800-22r1a Section 2.2.7.) 

Non-Overlapping Templates 9 The Non-Overlapping test reguires selection of a template length of 9 or 10 in order to produce 

template lengih meaningful results. (See SP 800-22r1a Sections 2.7.7 and 2.8.7.) For a template length of 10, the 
MAXNUMOFTEMPLATES constant (in defs.h) should be set to at least 284 prior to compiling STS, 
otherwise most 10-bit aperiodic templates with a leading 1 bit are discarded. 

Overlapping Template length 9 The Overlapping test reguires selection of a template length of 9 or 10 in order to produce 
meaningful results. When n106, the template size of 9 comes closest to fulfilling the parameter 
selection criteria. (See SP 800-22r1a Section 2.8.7.) 

Universal block length (L), L—7, O-1,280 The Universal test block length (L) and initialization steps (0) must be consistent with the table in 

number of initialization steps (O) SP800-22r1a Section 2.9.7. For n106, the only acceptable values are (1-6, 0-640) and (L—7, 
01280). Note, any parameters passed into this test are discarded, and reasonable values are 
internally set. For n106, STS automatically uses the parameters recommended here. 

Approximate Entropy block 8 For the Approximate Entropy (ApEn) test, SP 800-22r1a Section 2.12.7 reguires the block length to 

length be less than (log2 n| - 5. Other analysis (Hill 2004) has shown that for n—1,000,000, block lengths 
greater than 8 can cause failures more often than expected for large scale testing. 

Serial block length 16 The Serial Test block length is also set based on n. If n106, the block length must be less than 17. 
(See SP 800-22r1a Section 2.11.7.) 

Linear Complexity block lengih 1,000 The Linear Complexity test block length is reguired to be set to between 500 and 5,000 (inclusive) 


and reguires that (See SP 800-22r1a Section 2.10.7.) 
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